Unable to get Zigbee thermostat recognized

[w.vuyk]

Hi All,

@w.vuy.k

New using deconz and JowiHue. In DeconZ I see the ZigBee devices I have added. If I open the menu, and look at the clusters/all data points, I see all the different menus, points.

In JowiHue, the device was created only with on/off and with none of the other characteristics of the device.

How do I get the other device points to appear in Hue. Do I have to erase it from Hue and refresh, create points manually?

Any help/direction would be greatly appreciated.

Joel,

This thread is about thermostats, but I understand you are adding different types devices? For the future it is better to start a new thread so I do not get too confused here

It will help me if you could post the JSON that is shown on the HS device that was created on to the properties of the device and select the JowiHue tab. On the bottom of this page you will se the text string. Could copy and paste this for me, so I can have a look at the details?

I saw you have posted a device request on the github, which is a good thing, because the device types are not mentioned yet on github and probably not yet fully supported. Normally, if they add the support the plugin will recognise them directly as there are no unknown sensor functions on these devices.

I will als keep an eye on the two issues on github

Wim

[zguy]

I am adding the Sinope Smart Plug & Smart Controller (ZigBee) RM3250ZB & SP2600ZB

I don't know about these devices. I do know about Sinope though. I had an issue with one of their thermostats that failed. I initially was happy with them as they responded quite fast in replacing the failed device. But I'm no longer so happy as they are not answering more technical questions regarding a few more issues I have with their Zigbee thermostats. I'm pretty certain it's because I no longer use their GT130 gateway, but that is another story.

I have added the devices in Phoscon app. The devices and all their clusters are populated in deCONZ. I can communicate and control/read the clusters/data via deCONZ. The issue is that JowiHue, imported the device as an on/off device with only on/off as a command. It doesn't import any of the other clusters. I want to see the live amperage/wattage/voltage readings found in the Electrical Measurement & Simple Metering Cluster.

We'll see what @w.vuyk will suggest, I'm sure he will chime in soon. Yet, my suggestion would be to stop the JowiHue plugin then delete all related devices in HS. After that, go back to deCONZ and re-read all clusters of the relevant devices. After that re-enable the JowiHue plugin and see what it discovers.

Did you check those devices are supported by deCONZ? I had to do a bug report for the then supposedly supported thermostats device I'm using.

In regards to REST-API, where do I find this command/query/app. When I click REST-API in the deConz app, it takes me to the Phoscon app (website).

You need to add an extension to your browser. I use Postman on Chromium. Once you got that, you can point to your deCONZ device with several URLs. But first, you need to register the tool into deCONZ. Check the API docs from deCONZ for more info.

So the question is can we get the device's clusters/ their data points imported with the device so that we are able to see all the relevant data points from within JowiHue, or will it only take the core (switch) device from Phoscon and none of its attributes.

The answer to this really depends on what the REST-API reports. Whatever is in there should be readable by the JowiHue plugin because it uses the same API to get its information. That said, I do have power related devices showing in HS for the Sinope thermostats. It's not consistent between of thermostats firmware revision difference though, again a pending question I have with Sinope.

[JoelWener]

I am adding the Sinope Smart Plug & Smart Controller (ZigBee) RM3250ZB & SP2600ZB

I have added the devices in Phoscon app. The devices and all their clusters are populated in deCONZ. I can communicate and control/read the clusters/data via deCONZ. The issue is that JowiHue, imported the device as an on/off device with only on/off as a command. It doesn't import any of the other clusters. I want to see the live amperage/wattage/voltage readings found in the Electrical Measurement & Simple Metering Cluster.

In regards to REST-API, it brings up only on/off (what is in Phoscon).

So the question is can we get the device's clusters/ their data points imported with the device so that we are able to see all the relevant data points from within JowiHue, or will it only take the core (switch) device from Phoscon and none of its attributes.

[zguy]

Hi All,

New using deconz and JowiHue. In DeconZ I see the ZigBee devices I have added. If I open the menu, and look at the clusters/all data points, I see all the different menus, points.

In JowiHue, the device was created only with on/off and with none of the other characteristics of the device.

How do I get the other device points to appear in Hue. Do I have to erase it from Hue and refresh, create points manually?

What kind/brand of device are you using?

FWIW, here is the surest way I found to get the device in JowiHue HS plugin. Others, @w.vuyk included, may have a different experience / opinion.

1. Disable JowiHue plugin in HS
2. Add the device using Dresden Phoscon app. If the device is not readily available in Phoscon, this will error out. But the device will be added to the deCONZ GUI and Zigbee radio. If it doesn't error out, rename the device from within Phoscon to something relevant. This will immediately show in deCONZ and eventually in HS.
3. Whatever happens in Phoscon, in deCONZ you want to look at all the device clusters. Whenever you see a read button, press it, wait for the values to populate and go to the next. Do this until you have read everything available. At this point, deCONZ will have everything it could learn from the device. You can verify what it found by using the REST-API. What you'll find in the REST-API is what the JowiHue plugin will see when you restart it.
4. If you have multiple device, repeat the above procedure. Or do 1 device at a time, your choice. In this case, I usually add just one (reason below) and verify it got added properly in HS before adding the remaining ones.
5. Re-enable the JowiHue plugin. By default it usually re-scans the Zigbee devices. Watch HS log. If the plugin doesn't add any devices, do a manual scan from the plugin settings.

About adding the devices manually in HS or deleting them from HS or deCONZ, my experience is mitigated. Adding in HS won't do much as the corresponding device doesn't exist in deCONZ. Point is totally moot. Deleting devices in HS is pretty much the same as the next plugin re-scan will find it and re-add it to HS.

Deleting a device in deCONZ is where it gets mitigating. I had a bad experience with a Philips Hue motion sensor. I had bought a bunch of them, 7 or 8. All but one were added properly in both deCONZ and HS. I still have to clean up the messy one. But here is what I learned in the process. Each Zigbee device has a unique device ID called a MAC address, much like any other network devices you'd find on your home network. Deleting a device from deCONZ doesn not remove it completely. Why? I don't know. If you do delete a device from deCONZ and try to re-add it, it will recognize the device MAC address and re-add it with the same MAC address as before and the same functionalities found in the original add.

This is unfortunately less than optimal and prevent re-adding a device as a true new one. I returned the Philips sensor because of that.

Dresden deCONZ/Phoscon implementation is still in its infancy I think. Yet, in most case it does the job, at least for me. So far I have about ten motion sensors and 3 floor heating thermostats running on it and all controllable with JowiHue plugin. It's still far from perfect but it does works for most basic device functionalities.

[JoelWener]

Hi All,

@w.vuy.k

New using deconz and JowiHue. In DeconZ I see the ZigBee devices I have added. If I open the menu, and look at the clusters/all data points, I see all the different menus, points.

In JowiHue, the device was created only with on/off and with none of the other characteristics of the device.

How do I get the other device points to appear in Hue. Do I have to erase it from Hue and refresh, create points manually?

Any help/direction would be greatly appreciated.

[zguy]

zguy

Thanks for the additional info. It definitally clears up why there are two devices created by the plugin - it is not a fault in deCONZ (!!), it is a unexpected effect in the plugin. A bit technical explanation on this: The deCONZ REST API creates an entry (sensor or light entry) per main function of a device, like temperature, motion, watersensor etc. All these functions can come from one physical device. To recognize to what physical device these entries belong the "uniqueid" is used - a mac address really. If you check the above JSON's coming from the plugin, they all have the same start of the uniqueid.

Hey @w.vuyk, glad I could bring some insight into this.

Normally the plugin combines them all to one device, But the thermostat is a different developed device, which I created for a European valve as this was the first device that was supported by deCONZ. But clearly this has changed now. New functions, like a second temperature, power measurement and usage are available. The good thing is the plugin is not stressing on it, it just creates an extra device to support then (proud daddy really ). The features are updated fine.

I will work on to enable these features for the main device, but will leave it as is for now as nothing is wrong at this point. For a future release.

Alright. Whenever you can. Would much prefer having a single device instead of two indeed.

(proud daddy really ): You can, LOL, but also your great support is very much appreciated.

As for the two temperatures, I do wonder what they are. For my valve, the temperature beloning to the ZHAThermostat entry (the first device) is the temperature on the device itself, logical, but then you say ambient measurement, is this still on the physical device, does it have a remote device?
Wim

The TH1300ZB thermostat support an external / remote temperature sensor, presumably outdoor. There is a connector for it on the thermostat board. I my case though, I'm not using that feature.

The other possibility for this device could be the floor sensor as well.

Again, that is not clear to me. I've asked Sinope about this and a couple of other things. But they no longer respond.

[w.vuyk]

zguy

Thanks for the additional info. It definitally clears up why there are two devices created by the plugin - it is not a fault in deCONZ (!!), it is a unexpected effect in the plugin. A bit technical explanation on this: The deCONZ REST API creates an entry (sensor or light entry) per main function of a device, like temperature, motion, watersensor etc. All these functions can come from one physical device. To recognize to what physical device these entries belong the "uniqueid" is used - a mac address really. If you check the above JSON's coming from the plugin, they all have the same start of the uniqueid.

Normally the plugin combines them all to one device, But the thermostat is a different developed device, which I created for a European valve as this was the first device that was supported by deCONZ. But clearly this has changed now. New functions, like a second temperature, power measurement and usage are available. The good thing is the plugin is not stressing on it, it just creates an extra device to support then (proud daddy really ). The features are updated fine.

I will work on to enable these features for the main device, but will leave it as is for now as nothing is wrong at this point. For a future release.

As for the two temperatures, I do wonder what they are. For my valve, the temperature beloning to the ZHAThermostat entry (the first device) is the temperature on the device itself, logical, but then you say ambient measurement, is this still on the physical device, does it have a remote device?

Wim

[zguy]

I am going to put together information to open a deCONZ ticket, but as I am not really well versed in this technology, I would like to understand a few things... I am not sure how you create the various device components, so for instance I see the mode control in deCONZ and it has a drop down element (ambient/floor) that I can change thru deCONZ, so is this something that should be presented to your PI? In general I want to make sure I have some idea what is a deCONZ issue and what is not. what do I look at to see where you are picking up the info.

bobm4242 let's join the effort with deCONZ. With both of us providing information I'd hope for a more complete solution.

QUICK UPDATE: I do think the 2 device issue is deCONZ. After rebooting it seems that the Device name in deCONZ either changes or there is another device that is not showing up in the display. In deCONZ I sometimes see Thermostat 15 OR Temperature 12 (but never both)

It is. I provided the info for Wim in the previous post. I'm pretty sure this comes from an issue in deCONZ where whenever you delete a device in either deCONZ or Phoscon app, there is something lingering somewhere with the MAC address of the device that makes it link to some remains somewhere whenever you re-add a previously added device.

Gee, that one isn't easy to explain when English isn't your primary language.

[zguy]

zguy

The current official release is 2.10.4 the latest beta is 2.11.0. Lots of changes in the last release for sure. So it might be very possible some update has been done on the thermostats as well. It is a challenge though to find the details as not all is documented every clearly.

Wim, how did you learn about the new release? Can we get notification whenever they release an update?

[*]If clusters can change a mode from ambient to floor and vice versa, this would need to be made clear to the devs at github, with a sample which action is done in deCONZ and a request to enable this in the REST API as a to be set action.

Agreed. That can be changed in the clusters and there should be something available in the REST-API so we get this control in HS. That's a deCONZ issue to get fixed.

[*]The same would be valid for changing the DST (if possible through the clusters)

I haven't found a way yet to do this within the clusters.. Nevertheless, if the Sinope GT130 can address DST changes and time adjustments, there must be a way to do it. I've asked Sinope about this but they suddenly got silent.

I am surprised that you have two devices on the thermostat? One for temperature (temperature 8?) which is including wattage and the thermostat? Could you also post the Json on the temperature device for me? It looks like decONZ presents this really as a different device. Or am I wrong here and is this something else?

I also have 2 HS devices for each thermostats.



2nd one seems more like a status device while 1st looks more like a control device.

Interesting to note that in the status device, only the kWh device reports a current value.

Also, in the status device, the external temp is my interpretation, it could very well be something else like maybe the floor temp. But the value for the temperature device shown in the control device corresponds to the temperature shown on the thermostat display.

There is are 3 devices in the REST-API, , one labelled "8", then a second one labelled "9" and a 3rd one labelled "10". How does that yields 2 devices in HS? No idea.

Now, REST-API info:

 "8": {
"config": {
"offset": 0,
"on": true,
"reachable": true
},
"ep": 1,
"etag": "058987937cafdc7fba7ece28db6ad1dc",
"lastseen": "2021-04-21T03:25Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"lastupdated": "2021-04-21T03:23:18.560",
"temperature": 2350
},
"swversion": "746",
"type": "ZHATemperature",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0402"
},
"9": {
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "d84985d4f608d0173f9440385bb1886a",
"lastseen": "2021-04-21T03:25Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"consumption": 185572,
"lastupdated": "2021-04-21T03:25:28.574",
"power": 0
},
"swversion": "746",
"type": "ZHAConsumption",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0702"
},
"10": {
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "352b5926ed885c3562fd5268975e07b5",
"lastseen": "2021-04-21T03:25Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"current": 1000,
"lastupdated": "2021-04-21T03:22:11.558",
"power": 0,
"voltage": 240
},
"swversion": "746",
"type": "ZHAPower",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0b04"
},

And the JSON from the plugin:

Control device:

ZHAThermostat

**************************** Object info *****************************
{
"config": {
"heatsetpoint": 1800,
"locked": false,
"mode": null,
"offset": 0,
"on": true,
"reachable": true
},
"ep": 1,
"etag": "ae0e418e3151bcb5ae059a25c6261db3",
"lastseen": "2021-04-21T03:28Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "TH1300ZB (2)",
"state": {
"lastupdated": "2021-04-21T02:33:48.796",
"on": false,
"temperature": 2348,
"valve": 0
},
"swversion": "746",
"type": "ZHAThermostat",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0201"
}
************************* End Object info ***************************

And the status device:

ZHATemperature

**************************** Object info *****************************
{
"config": {
"offset": 0,
"on": true,
"reachable": true
},
"ep": 1,
"etag": "7d2f961f4ae854acdd77e9ebce4c3222",
"lastseen": "2021-04-21T03:30Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"lastupdated": "2021-04-21T03:28:18.585",
"temperature": 2344
},
"swversion": "746",
"type": "ZHATemperature",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0402"
}
************************* End Object info ***************************




ZHAConsumption

**************************** Object info *****************************
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "3320f86ca9035f5dd410112f955c0b69",
"lastseen": "2021-04-21T03:30Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"consumption": 185572,
"lastupdated": "2021-04-21T03:30:28.599",
"power": 0
},
"swversion": "746",
"type": "ZHAConsumption",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0702"
}
************************* End Object info ***************************




ZHAPower

**************************** Object info *****************************
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "95b13c69f6dc2d1bba89dfba49c3ec67",
"lastseen": "2021-04-21T03:30Z",
"manufacturername": "Sinope Technologies",
"modelid": "TH1300ZB",
"name": "Plancher SDB Status",
"state": {
"current": 1000,
"lastupdated": "2021-04-21T03:27:11.583",
"power": 0,
"voltage": 240
},
"swversion": "746",
"type": "ZHAPower",
"uniqueid": "50:0b:91:40:00:02:18:52-01-0b04"
}
************************* End Object info ***************************

[zguy]

@zguy

Hopefully I have answered all your questions below (although in no particular order ).

I am running Phoscon 2.11 with the latest firmware, although who knows what the differences are with the Conbee2 and RaspBee?

Cool!

My understanding is both RaspBee2 and ConBee2 should behave the same. Both are essentially the same Zigbee radio transmitter but fitted in a different housing, either a Raspberry PI PIO hat board or a USB dongle. The Zigbee network is stored within the radio transmitter.

I saw a thread somewhere on adding a thermostat to deCONZ/Phoscon, it said to initiate the scan sensor, and then query one of the clusters. I have tried this several times and so far it has worked consistently (including adding the device in Phoscon), but agree they should be able to detect the device since they say they support it.

That is pretty much the only way I was able to add the thermostats in the beginning.

A couple of things I've noticed so far regarding adding devices to deCONZ:

• disabling Jowihue PI in HS prior to adding in Phoscon helps with the final result
• then add the device via Phoscon using "add sensor"
• in the earlier releases I had, that used to fail in Phoscon, yet deCONZ would see the thermostat. Later releases would succeed in adding a sensor in Phoscon app
• when you get a successful add in Phoscon, rename the device from Phoscon. That immediately reflects in deCONZ
• then, in deCONZ, read all the device available clusters
• at this point, I check the REST-API to confirm deCONZ is seeing and exposing what is expected as that is what the plugin will see
• re-enable the Jowihue PI in HS

The above procedure is what I found is the most reliable way to add devices to deCONZ and have them reflected in HS.

I still have discrepancies between the 2 thermostats with the same firmware release but they didn't go thru the above procedure. I'll have to re-add them following the above procedure at some point to see if I get consistent results.

One thing to note, each device has a unique MAC address. Once a device has been added to deCONZ, it seems to remember that, even if you deleted the device from it. I currently have a Philips Hue motion sensor that didn't get added properly the very 1st time. Since then, no matter what I tried, I can't get this device to work properly in Jowihue PI. This may become an issue when I get to the point of re-adding the thermostats...

The time on my unit is correct but I have not gone thru a DST change.

Expect no change. I've been told by Sinope that is handled by the Sinope gateway. Unless we find a way in the clusters. I've asked Sinope about this but they didn't answer any further.

I am still trying to figure out which of the temperatures being reported is Floor and which is room, I will need to trigger the floor heat so it is warmer than the room temp just so I can differentiate which is which.

Same boat here. One of them corresponds to the display. Not sure about the other one.

Wim is great to work with, I am not super familiar with this technology, so I am not 100% what he can and can't address.

Agree for Wim, I wouldn't be using that many Zigbee devices, thermostats and hue motion sensors, without his help. Yet, he is limited with what his plugin can see from deCONZ REST-API.

I really wish Sinope had continued with the RF models, never had an issue with the GT125 and the Spud PI. Sinope does not seem to very cooperative, which is a shame as this is by far the best option for Floor Heating that is not wifi.

I couldn't care less for a gateway that is internet dependent, be it the GT125 or the GT130. I've used the GT130 for a while because I didn't have the choice. But as soon as I heard about the Conbee/Raspbee, I switched. It's been painful, agreed, but in the end, worth it. The system has to work, internet or not. And now it does, albeit not perfectly.

I had good support from Sinope when one of the thermostat failed. They replaced it in a timely fashion. But no that I'm asking deeper questions I'm not getting much answers. Sad.

[bobm4242]

Thanks I will gather up all the info and report the bug. Thanks again

[w.vuyk]

The plugin gets all from deCONZ REST API. I am sure ambient/floor setting is not send through the REST API, so you could emphasize that in the ticket. Is this for the temperature display? If it is, then mention you would need both to be reported. The issue you post, could also point to the issue 4101

Also, post the JSON from the thermostat and temperature devices. Tell the uniqueid is different between power measurement, temperature and thermostat , where it would be expected to be the same for all.

And be sure to follow their template and not skip parts as they are very strict on following this template. Log this as a bug....

Thanks

Wim

[bobm4242]

Wim, Thanks again for your quick response. I will get this data to you asap. (UPDATE: emailed it to you let me know you have received it)
I have done some testing and have observed the following.

The 2 Temps that are reporting are in two different clusters (and one in each device that is in HS). These are BOTH reporting the Floor temp. I see nothing that actually is reporting the room temp. So these values are being reflected in your PI from both sensors correctly (just in the two devices). I will check to see if I swap control from Floor to ambient if then those same sensors start picking up the room temp.

I am going to put together information to open a deCONZ ticket, but as I am not really well versed in this technology, I would like to understand a few things... I am not sure how you create the various device components, so for instance I see the mode control in deCONZ and it has a drop down element (ambient/floor) that I can change thru deCONZ, so is this something that should be presented to your PI? In general I want to make sure I have some idea what is a deCONZ issue and what is not. what do I look at to see where you are picking up the info.

QUICK UPDATE: I do think the 2 device issue is deCONZ. After rebooting it seems that the Device name in deCONZ either changes or there is another device that is not showing up in the display. In deCONZ I sometimes see Thermostat 15 OR Temperature 12 (but never both)

Thx Bob

[w.vuyk]

2 devices are created, but when I look at the Json part, there should be only one device. No expected. Could you try to recreate the device once more(no need to delete the devices in deCONZ!) following these steps:

1. Enable verbose tracing and log to file in the settings of the plugin
2. Then stop the plugin (I need to see the start of the plugin later)
3. Remove both devices from HS
4. Start the plugin and let it create the devices
5. Disable the verbose tracing and log to file options
6. Send the file \Logs\JowiHue.log to me (jowihue at ziggo dot nl)?

I hope I can find a reason why the devices are splitting.

Thanks,

Wim

[bobm4242]

Starting a new entry seems my issue was that I left deCONZ down at some point (duh).
In any case I deleted the device form HS and deCONZ to start over.
followed same process added the device to deCONZ and then did a second scan for sensors anddoing a read of a cluster. Thermostat 15 is created (or the xHHHH is renames).
2 devices are created in HS.


Test setting the set point. and this works fine

And this is the JSON string for Temperature 12
ZHATemperature

**************************** Object info *****************************
{
"config": {
"offset": 0,
"on": true,
"reachable": true
},
"ep": 1,
"etag": "1c41ac194cfcb31c2b0a53f60ca45c73",
"lastseen": "2021-04-17T04:18Z",
"manufacturername": "Sinope",
"modelid": "TH1300ZB",
"name": "Temperature 12",
"state": {
"lastupdated": "2021-04-17T04:13:35.849",
"temperature": 1939
},
"swversion": "746",
"type": "ZHATemperature",
"uniqueid": "50:0b:91:40:00:02:1e:4e-01-0402"
}
************************* End Object info ***************************

ZHAConsumption

**************************** Object info *****************************
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "621e8d19082397e6e78ff8b7f5ddbd4c",
"lastseen": "2021-04-17T04:18Z",
"manufacturername": "Sinope",
"modelid": "TH1300ZB",
"name": "Consumption 13",
"state": {
"consumption": 0,
"lastupdated": "2021-04-17T04:18:12.857",
"power": null
},
"swversion": "746",
"type": "ZHAConsumption",
"uniqueid": "50:0b:91:40:00:02:1e:4e-01-0702"
}
************************* End Object info ***************************

ZHAPower

**************************** Object info *****************************
{
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"etag": "a7d9dd01c4c71e0381500a338c27ee0d",
"lastseen": "2021-04-17T04:18Z",
"manufacturername": "Sinope",
"modelid": "TH1300ZB",
"name": "Power 14",
"state": {
"current": 2300,
"lastupdated": "2021-04-17T04:18:12.874",
"power": 0,
"voltage": 120
},
"swversion": "746",
"type": "ZHAPower",
"uniqueid": "50:0b:91:40:00:02:1e:4e-01-0b04"
}
************************* End Object info **