DeCONZ, ZHA and Zigbee components and compatible hardware

I have recently installed a conbee stick in my hass.io install. Running the deconz addon by marthoc.

I have successful integrated some spare devices (Osram Smart Plug, a Xiaomi sensor) and a couple of dimmers (philips and xiaomi). The only thing that I can’t see in HA is the temperature that phoscon shows on the xiaomi sensors (I didn’t know the sensors had a temperature sensor). I guess there is also an error in the battery level of the sensors.

I already own a philips hue bridge with twenty bulbs and a Xiaomi gateway with ten sensors.

My main goal is removing the xiaomi gateway and creating a single Zigbee network.

Now I am facing the possibility of moving the other sensors (philips and xiaomi) to deconz. (The philips sensors are read with the hue.sensor component, and I expect a shorter update time)

Based in your previous experiences, what is the best way of doing the migration? One device at a time?

Is there a recommended naming of the devices?

I don’t want (yet) to remove the Hue bridge (and app), because the family prefers it over phoscon or HA… but I’d appreciate your suggestions to facilitate the migration from Hue to deconz.

Thanks in advance!

Well, start with the Xiaomi gateway first, family will notice an increase in responsiveness, so only positive.

If they want to absolutely use the Hue app, you need to stay with the Hue bridge too.

I suggest to use HA CLIENT as Android app, its excellent, and if you do a nice homepage, it’s way better than the Hue app. When family is ready for the change you move the Hue devices over deconz
Hopefully soon will be ported also for IOS

1 Like

If you set deconz to port 80 most hue apps should work linked to Deconz.

I moved one light at a time. And kept the same naming convention so automations would continue to work.

For Xiaomi sensors that also presents temperature there is no support for it in the component since they apparently aren’t very reliable and can have quite a large offset from reality

1 Like

The log gives many errors, and the dimmer is not working right, I guess the code is not completed.

I think most user case the dim and off button are fine with the functionality given by the phoscon app. I wish I could program the ON button (multiple click for multiple scene

What are the logs?

Well, I deleted everything, something is very wrong with one dimmer (I have two), On the one on which I did not play, all works fine, I found the phoscon app working well enough to assign scene to keys, I am happy with it, no need to use appdaemon for my user case, happy with phosocn programming.

Now with the dimmer that I experimented with, it acts now weirdly (not working) even with the phoson app ( I tried to reset it, by pressing the button in the hole for 10 seconds).

Is there any way, additional to resetting, to make it disappear entirely and start the process of pairing from scratch? I say so because even after resetting it, when reparing the device is clearly recognized as previously beeing in the deconz system

Hmm, I haven’t done it but it should be to remove it in phoscon and then reset it

Bought a Tradfri led driver and remote control. Few minutes and all is connected to deconz and HASS
Best system available. Top!

1 Like

Anyone had this issue with IKEA Trådfri light bulbs and deCONZ before?

I turned off two of the lights through HomeAssistant, light 1 and light 2, afterwards I also powered off light 2 on the power switch. Four minutes later light 1 was automatically turned on again, 16 seconds after that light 2 was updated to the expected "reachable: false".

Why did light 1 automatically turn on again 4 minutes after I turned it off?

There were no logs about HomeAssistant sending anything to the RestAPI before light 1 was turned on, so it appears as either deCONZ or the light bulb itself decided that it should be turned on. Also, there were no logged reachable event for light 1 so it doesn’t appear as if the reachable state was toggled or something like that.

Logs:

2019-01-21 21:35:32 DEBUG (MainThread) [pydeconz.utils] Sending {'data': '{"on": false}'} to http://<obscured>/api/<obscured>/lights/1/state
2019-01-21 21:35:32 DEBUG (MainThread) [pydeconz.utils] HTTP request response: [{'success': {'/lights/1/state/on': False}}]
2019-01-21 21:35:32 DEBUG (MainThread) [pydeconz.deconzdevice] light_1: update on with False
2019-01-21 21:35:32 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"1","r":"lights","state":{"on":false},"t":"event","uniqueid":"<obscured>"}
2019-01-21 21:35:32 DEBUG (MainThread) [pydeconz.utils] Sending {'data': '{"on": false}'} to http://<obscured>/api/<obscured>/lights/2/state
2019-01-21 21:35:33 DEBUG (MainThread) [pydeconz.utils] HTTP request response: [{'success': {'/lights/2/state/on': False}}]
2019-01-21 21:35:33 DEBUG (MainThread) [pydeconz.deconzdevice] light_2: update on with False
2019-01-21 21:35:33 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"2","r":"lights","state":{"on":false},"t":"event","uniqueid":"<obscured>"}

[ ... 4 minutes later ]

2019-01-21 21:39:12 DEBUG (MainThread) [pydeconz.deconzdevice] light_1: update on with True
2019-01-21 21:39:12 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"1","r":"lights","state":{"on":true},"t":"event","uniqueid":"<obscured>"}
2019-01-21 21:39:28 DEBUG (MainThread) [pydeconz.deconzdevice] light_2: update reachable with False
2019-01-21 21:39:28 DEBUG (MainThread) [pydeconz.websocket] Websocket data: {"e":"changed","id":"2","r":"lights","state":{"reachable":false},"t":"event","uniqueid":"<obscured>"}

That’s a weird one that you probably need to create an issue on deconz github to resolve

Do you have Phillips hue bulbs within deconz? It happened the same to me. Eventually it will fix by itself (it took two weeks to me) as if I remember correctly is something with how the ikea bulbs handle the neighbors nodes if they are not ikea. During that time I created an automation on node red to check if the status of the bulb was the same as a input-Boolean created to control this bulb at any change on the bulb.

No Philips Hues, only IKEA Trådfri connected. It didn’t repeat this behavior until today.

I moved one of my IKEA Trådfri lights to the same room earlier today, also connected a new Trådfri E14 to the same network (and same room). And for the last hour the same Light 2 have been doing this 6-7 times, every 5-10 minutes. It receives a "reachable: true" and defaults the color to its default color.

I guess I’ll need to report this to deCONZ.

Would it be possible to support thermostats in the deconz component?

There was a commit not long ago in the deconz repo that add support for a specific thermostat:
https://github.com/dresden-elektronik/deconz-rest-plugin/pull/1003

These things are really cheap nowadays because a lot of them were sold by a major telco in germany to push their smart home system (apperantly didn’t go so well, I picked up one for 20€ on ebay :slight_smile: )

The sensor is present in the deconz API and setting the threshold also works. Temperature format is a bit wierd though.

sensor data:

{
  "config": {
"battery": null,
"heatsetpoint": 2200,
"offset": 0,
"on": true,
"reachable": true,
"scheduler": null,
"scheduleron": false
  },
  "ep": 1,
  "etag": "4ac798aad6ca213c513190e29c5992ed",
  "manufacturername": "Bitron Home",
  "modelid": "902010/32",
  "name": "902010/32",
  "state": {
"lastupdated": "2019-01-27T14:08:54",
"on": false,
"temperature": 2400
  },
  "swversion": "V1b225-20151013",
  "type": "ZHAThermostat",
  "uniqueid": "00:0d:6f:00:04:24:72:4f-01-0201"
}
2 Likes

Absolutely

What does the different parameters do and how do you set them?

shamelessly copied from the PR :slight_smile:

option read/write attribute description
state.on read only 0x0029 running state on/off
state.temperature read only 0x0000 measured temperature
config.heatsetpoint read write 0x0012 heating setpoint
config.scheduleron read write 0x0025 scheduler on/off
config.offset read write 0x0010 temperature offset
config.scheduler read write (command) scheduled setpoints

Most important is the option config.heatsetpoint, this controlls the desired temperature.

config.scheduler is an array to set diffrent temperatures for time/date ranges. For example while nobody is at home Mo-Fr 7:00 - 18:00 18°c, after that 22°c.

Personally i am not really intrested in that, as the floor heating takes at least 2 hours to react and constantly changing the temperatures seems to be inefficant.

I should also open an issue at the deconz github, because setting the time cluster just displays an empty dialog:

image

1 Like

Are you willing to try out a beta in a couple of days?

Sure, i can mount the thermostat in my office and test it :slight_smile:

Beta for the whole homeassistant or only pydeconz / deconz component?

Home assistant. I can put up a PR sometime this week

1 Like

Can I get an explanation of what is ZHA?

I mean I know Zigbee is the protocol, deCONZ is the soiftware by Dresden, but what is ZHA???

On a technical level:

Zigbee defines a standard for wireless mesh communication technology.
There are different profiles that a Zigbee device can implement, for example:

  • ZHA: Zigbee Home Automation
  • ZLL: Zigbee Light Link

Different profiles may exist in the same Zigbee network.

Then there is the Home Assistant implementation where the author decided to name his component zha (https://www.home-assistant.io/components/zha/)

In my opinion thats a bit misleading as it supports also ZLL