If I understand your comment on the Pull Request correctly you did squash your commits. A squash results in a rewrite of the Git history, meaning you have to do a forced push (-f option). If you push into your branch it will directly part of the existing Pull Request.
ok, seems all worked out ā¦ lets see.
@hehold a test version with the new sensors is online but you would have to download the jar there and drop it handish into your addon folder and then probably activate that addon in the console.
if you donāt want to fiddle around with that i am afraid you have to wait until it is approved for a merge.
if you run into problems, you are welcome to ask here as well.
Took me some time to figure out how to install the Snapshot-version, but I finally managed it 
The consumption is working fine, but Iām struggling with the power values. I donāt get any values for that. Also in the documentation you havenāt mentioned a channel for power. Is this still missing or am I doing something wrong?
My configuration looks like this:
Number:Power bitronsd01s_watt "Verbrauch [%.1f W]" {channel="deconz:consumptionsensor:homeserver:bitronsd01s:power"}
Number:Energy bitronsd01s_cons "Cons [%.1f Wh]" {channel="deconz:consumptionsensor:homeserver:bitronsd01s:consumption"}
Hi,
quick update: Today, i downloaded the latest deconz binding snapshot as jar from:
https://openhab.jfrog.io/openhab/webapp/#/builds/PR-openHAB2-Addons/11949.
Using this version, auto discovery still does not work, however, after adding the aqara temperature and open\close sensors manually the item values get now updated.
Thanks to all who are working on the binding. You guys made my day!
Cheers Radio
Power sensor | ZHAPower, CLIPPower | powersensor | power
The Power thingie needs to be a powersensor from what i would guess. i put the corrected version below, hope that one works. i also had once the wrong unit in the brackets, so openhab refused to show values, because it couldnt convert the values. i thing i had copied Ā°C from somewhere instead of %. so now i use %unit% always, as long as it returns the unit i want, this way i can be sure i donāt fā¦ up the units. but in your example Watts should work. But lets say the programmer screwed it up and put the unit of W/h in there, then openhab might refuse to show values because it cant conver W/h into your wanted W, although you would be perfectly right. so as i said, if you wanna work safe, just use %unit% and see what it returns and then change the unit to what you want, would be my recommendation. i didnt try that but for example openhab should be able to convert the Watts into Joule for example, but not in Ā°C or Cows 
for me that showed in the value changing from NULL to UNDEF
i order 2 innr SP 120 power sockets which should arrive this week, so i can test those things as well.
Number:Power bitronsd01s_watt "Verbrauch [%.1f %unit%]" {channel="deconz:powersensor:homeserver:bitronsd01s:power"}
OK, seems I still havenāt understood how this ZigBee stuff is working 
I thought the consumptionsensor is responsible for "type": "ZHAConsumption" and will provide the channels to read state:consumption and state:power.
According to the binding documentation the powersensor is mapped to the resource types ZHAPower, CLIPPower but not to ZHAConsumption. Thatās why I did not think of using it to read the power values.
Is there no relationship between the thing types and the resource types? How does it work then?
Trying to understand as I might have to add ZHAWater support soon.
BTW, Iāve tried your item definition, but I only get --.
well, i probably should have linked some things files as well. for me atm without any power and Consumption sensors, since i dont have the hardware it looks like this.
Rest API
"2": {
"config": {
"battery": 88,
"offset": 0,
"on": true,
"reachable": false
},
"ep": 1,
"etag": "de63a6bd67d737da75b57caa9b346853",
"manufacturername": "LUMI",
"modelid": "lumi.weather",
"name": "MultiTemp 1",
"state": {
"lastupdated": "2019-01-13T08:10:50",
"temperature": 2069
},
"swversion": "20161129",
"type": "ZHATemperature",
"uniqueid": "00:15:8d:00:02:c8:d2:68-01-0402"
},
"3": {
"config": {
"battery": 88,
"offset": 0,
"on": true,
"reachable": false
},
"ep": 1,
"etag": "de63a6bd67d737da75b57caa9b346853",
"manufacturername": "LUMI",
"modelid": "lumi.weather",
"name": "MultiTemp 1",
"state": {
"humidity": 4782,
"lastupdated": "2019-01-13T07:50:45"
},
"swversion": "20161129",
"type": "ZHAHumidity",
"uniqueid": "00:15:8d:00:02:c8:d2:68-01-0405"
},
"4": {
"config": {
"battery": 88,
"on": true,
"reachable": false
},
"ep": 1,
"etag": "de63a6bd67d737da75b57caa9b346853",
"manufacturername": "LUMI",
"modelid": "lumi.weather",
"name": "MultiTemp 1",
"state": {
"lastupdated": "2019-01-13T07:50:45",
"pressure": 969
},
"swversion": "20161129",
"type": "ZHAPressure",
"uniqueid": "00:15:8d:00:02:c8:d2:68-01-0403"
},
Things config
Bridge deconz:deconz:41864904 "Phoscon Bridge BĆ¼ro" [ host="192.168.178.213", apikey="xxxxxx"] {
temperaturesensor temperature_1 "Aqara Temperatur 1" [ id="2" ]
humiditysensor humidity_1 "Aqara Humidity 1" [ id="3" ]
pressuresensor pressure_1 "Aqara Pressure 1" [ id="4" ]
}
Items Definition
Number:Temperature Temperature_Living_Aqara "Temperatur im Wohnzimmer [%.1f Ā°C]" <temp_inside2> (G_Aqara_Living,G_Aqara_Temp) {channel="deconz:temperaturesensor:41864904:temperature_1:temperature"}
Number:Dimensionless Humidity_Living_Aqara "Luftfeuchte im Wohnzimmer [%.1f %unit%]" (G_Aqara_Living,G_Aqara_Humid) {channel="deconz:humiditysensor:41864904:humidity_1:humidity"}
Number:Pressure Pressure_Living_Aqara "Luftdruck im Wohnzimmer [%.1f hPa]" (G_Aqara_Living,G_Aqara_Pressure) {channel="deconz:pressuresensor:41864904:pressure_1:pressure"}
This is just one piece of hardware that gets these three things and itemsā¦ seems like deconz prefers to transmit those seperate instead of creating one item with 3 channels, which would work as well.
i assume for your socket itĀ“s about the sameā¦ as i said, will get 2 innr sockets and see how they work and get detected.
Ok, now Iām starting to understand whatās going on. In my case there is just one sensor with 2 state-items:
"2": {
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "3dfd7b4ba3b9f6758b5c7ae9fab5b6ee",
"manufacturername": "Bitron Video",
"modelid": "902010/25",
"name": "902010/25",
"state": {
"consumption": 8672,
"lastupdated": "2019-01-14T12:37:42",
"power": 0
},
"swversion": "20170420",
"type": "ZHAConsumption",
"uniqueid": "00:12:4b:00:16:47:73:1e-01-0702"
},
oha, i am not entirely sure if the binding is programmed to grab those 2 values in one state bracketā¦
@cweitkamp hmm, christoph, can you take a look at the post above, i guess that is unsupported atmā¦ didnt know a consumption sensor can have power and consumption state at the same time ā¦
Should work actually. The binding is reading all supported values and doesnāt care about the actual Zigbee type.
Two things of type power and consumtion with the same āidā should work.
hmm, but since autodetection doesnt work, he needs to set up a consumptionsensor then i guess and that should have 2 channels then, right ?
No, every sensor Thing has one channel in the current architecture. Two Things are required.
so he creates a power and a consumption thingie but both with id 2 ā¦ ?
@David_Graeff But doesnāt the lightsensor Thing have more than one channel? At least thatās how I would read this tableā¦
Iāve tested like this:
Bridge hue:bridge:00212E02F2E4 [ ipAddress="192.168.1.67", userName="6B2BB03D9" ] {
0010 bitronsd01 [ lightId="2" ]
}
Bridge deconz:deconz:homeserver [ host="192.168.1.67", apikey="6B2BB03D9" ] {
consumptionsensor bitronsd01 "Bitron SD01" [ id="2" ]
powersensor bitronsd01 "Bitron SD01" [ id="2" ]
}
Is it OK/recommended to use the same name ābitronsd01ā for all those things (it seems to be working)?
Switch bitronsd01_onoff "Bitron SD" [ "Switchable" ] { channel="hue:0010:00212E02F2E4:bitronsd01:switch" }
Number:Power bitronsd01_watt "Verbrauch [%.0f %unit%]" {channel="deconz:powersensor:homeserver:bitronsd01:power"}
Number:Energy bitronsd01_cons "Cons [%.0f Wh]" {channel="deconz:consumptionsensor:homeserver:bitronsd01:consumption"}
And here the result:
No, the thing id must be unique. I guess your openHAB is using only one Thing then and it seems to work anyway.
Hi all,
@David_Graeff already answered all questions. Thank you.
In detail: currently the design for things of the deCONZ binding tries to follow this table (see https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices#measured-values-legend):
| Attribute | Unit | Resource Type | |
|---|---|---|---|
| A | state.alarm |
bool | ZHAAlarm |
| b | config.battery |
% | (any battery-powered sensor) |
| C | state.carbonmonoxide |
bool | ZHACarbonMonoxide |
| d | state.dark |
bool | ZHAPresence |
| F | state.fire |
bool | ZHAFire |
| H | state.humidity |
0.01% | ZHAHumidity |
| L |
state.lightlevelstate.luxstate.darkstate.daylight
|
lux bool bool |
ZHALightLevel |
| l | state.lowbattery |
bool | (any IAS Zone sensor) |
| M | state.presence |
bool | ZHAPresence |
| O | state.open |
bool | ZHAOpenClose |
| P | state.pressure |
hPa | ZHAPressure |
| T | state.temperature |
0.01ĖC | ZHATemperature |
| t | config.temperature |
0.01ĖC | (any Xiaomi sensor) |
| p | state.tampered |
bool | (any IAS Zone sensor) |
| W | state.water |
bool | ZHAWater |
| V | state.vibration |
bool | ZHAVibration |
Please note some points:
-
Some sensors of the same type may support more channels than other ones (e.g. TRĆ DFRI motion sensor (Mbd) and Hue motion sensor (Mb)). In such case the channels will be added during runtime.
-
Some of the listed sensors are not yet supported by the binding (e.g. ZHAWater).
-
The consumption sensor is not yet listed.It is listed in the Supported Smart Plugs section.
Thanks a lot for your feedback. Unfortunately this is again something Iām having troubles to find/understand (started with OH and ZigBee only this year) ā¦ what is where.
I found consumption, but not under Sensors but SmartPlugs
And here my smart plug (Bitron 902010/25) is listed with Measured Values Cp and not P, thus I was expecting the power to be reported via a consumptionsensor and not a powersensor.
Is this thinking wrong? Other way round, what is the correct way to figure out which sensor to use to get the desired data, as in my case power from a Cp smart plug?
No, it is not. Indeed. Your opinion is very much appreciated.
Please keep in mind that we are facing a situation why we really need this discussion. A new OH2 user - do not get me wrong - tries to work with a very young binding. We are currently finishing touches with it.
So please keep ongoing.
I have to admit that I totally missed the Supported Smart Plugs table. The state.power attribute is not a mandatory information on a ZHAConsumption device. That is the reason why the OH2 thing currently does not support it. But imho we should improve this and add it to the binding. I will take care of that.
@hehold here, christoph was so kind to fix it right awayā¦ this should fix your problem once its mergedā¦