[deconz] Issues with automatic discovery of bridge and sensors and timeouts (all things go OFFLINE and ONLINE again)

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 :grinning:

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 :smile:

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 :confused:

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:
image

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.lightlevel
state.lux
state.dark
state.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

image

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…