Unable to get Zigbee thermostat recognized

[bobm4242]

@zguy

Once I saw that Spud was not going to be able to support the GT130, I decided not to purchase it. I first installed the unit, and hooked it up to the generic HS zigbee PI. It showed one value the current temperature. So started my search, and I came upon your thread. 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?



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.

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

I have changed the mode from within deCONZ (floor/ambient) but I will not be looking to change that value, but it would be nice to see in the PI.

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.

For the most part, floor set point is what I mostly need in HS as I will setting that based on various conditions within HS.

I actually have not triggered the start of heating so resting is what mine says but I will test that soon to see if it changes.

Agree with you on the list of needs for deCONZ.

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.

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.

Good Luck!
Bob

[w.vuyk]

zguy

I'm running deCONZ 2.09.03. Is that what you are running?

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.

• 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.
• The same would be valid for changing the DST (if possible through the clusters)
• I hope the external temperature you mention will report also over the REST API, and maybe that is just why bob's images are showing an extra thermometer (Bob: are you using an external (outdoor?) thermometer? ). Hope to get this cleared?

bobm4242

There should be no difference in the devicecompatibility between a Raspbee and a Conbee. So far I have seen there is none indeed.

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?

If the temperature device does not belong to the thermostat, the JSON of the thermostat you posted holds only one temperature. If this should report two temperatures, the devs on github have to be notified by either one of you so they can check with the clusters of your devices what is needed.

Wim

[bobm4242]

Well it looks like the device in deCONZ was renamed at some point to Temperature 8? Although I swear it was Thermostat 14 at one point



In Phoscon there is only one device also. It is listed as Power 10?



The setpoint in Thermostat 11 still functions, but the temperature for thermostat 11 has had no status update in a day. The thermostat 8 temperature reported in within the last few minutes. I only have the two on/off switches so these must be from the One device. But when your PI starts it only seems to report on the Therm8 entities.



Okay so oddly enough I just tried to get the JSON info for Therm8 and it seems I can't get the PI to talk with deCONZ.
I have rebooted the server and the deCONZ device several times, no luck, Not seeing your socket connection message.
I am going to delete the devices everywhere and start from scratch and see what gets generated.
I'll post again once I do that.

Thanks Bob

[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 **

[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]

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]

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]

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

[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.

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

[B]ZHAThermostat[/B]

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

[B]ZHATemperature[/B]

**************************** 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 ***************************




[B]ZHAConsumption[/B]

**************************** 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 ***************************




[B]ZHAPower[/B]

**************************** 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]

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.

[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]

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.

[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]

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.