Unable to get Zigbee thermostat recognized

[zguy]

That is good news. I will try to check in the plugin why it could not see the IP change. Did you deliberately change the IP, or is this a DHCP lease change?

Neither. I had setup a static IP on the PI long before it got configured in your plugin. The plugin never saw a DHCP assigned IP. No idea why but the .120 that was showing is in fact in the DHCP range.

If it happens again, it should be good to stop the plugin, delete the bridge device only in the HS device list and restart the plugin.

Wim

I'll try to remember that.

[zguy]

@w.vuyk, here is what I have in HS



2 devices, the second one showing 2 features statuses. That thermostat can accept a remote external temperature and also report on power consumption.

I'm guessing the one labeled "Status External Temperature?" is just that. However, I do not have a remote sensor connected so not much we can do to test this.

The one labeled "Status Watts" should be the power consumption. That worked with the Sinope gateway but apparently not yet with the deCONZ. At least the plugin recognize and talks to it, judging by the timestamp beside it.

On the 1st device, setpoint, mode and temperature work. I'm not certain exactly what the full heat does on the mode one though.

The heating setpoint doesn't work. It's stuck on "Resting" while it should show "Heating" when the thermostat powers the floor heating element.

As for the battery, I'm not aware the thermostat has one. It's a line powered device so... Unless there is a battery to maintain some stuff during a power failure, may be.

Events are also able to update the mode and setpoint.

SwoopX at Dresden has requested much information that I was able to supply and my understanding is that they are working on updating the REST-API to better work with the Sinope thermostat. Can't wait to see what they'll come up with. Yet, I'm very happy so far, much progress were achieved.

One odd thing, in the Phosconn app and in the REST-API, there is a virtual sensor device named "Daylight sensor". That didn't carry over to HS. I was expecting all devices seen in the REST-API would be brought in HS.

G.

[w.vuyk]

That is good news. I will try to check in the plugin why it could not see the IP change. Did you deliberately change the IP, or is this a DHCP lease change?
If it happens again, it should be good to stop the plugin, delete the bridge device only in the HS device list and restart the plugin.

Wim

[zguy]

Removed and re-added the bridge. Now seeing the thermostat in HS and able to control the setpoint.

It's late now so I'll play more with it tomorrow.

[zguy]

Seems I can't delete the bridge. Tried adding a new one. It saw the Phoscon at the right IP. But got this error:



And I now have the thermostat showing in Phoscon. I can also see it in REST-API /sensors.

[zguy]

The plugin not longer sees the RaspBee.



IP is wrong, should be .71. There doesn't seem to be an option to adjust that.

[zguy]

You mean showing 'thermostat nn' in the device box?


Cause it's still showing the hex value...

[w.vuyk]

That sounds good. Phoscon might be behind on these devices and not show the device. My plugin should show live responses once it sees the devices. The REST-API is a bit harder to check, you could find postman to read this. But the most important indicator is in deCONZ if the current name of the device (0x1E46 in your github post) changes to "Thermostat nn" in deCONZ, the REST API has accepted the device and will forward it directly to the plugin. No worries, we are getting close. Keep the developers attention at this point

[zguy]

Some progress. Removed and rejoined the thermostat. Now seeing activity, all clusters respond, even adjusted temp via the cluster.

A nice green line between the RaspBee and the thermostat too!

Phoscon, REST-API and your plugin still don't see it though.

What's the endpoint to use in REST-API for thermostat? As in http://192.168.1.xx/api/apikey/????

[w.vuyk]

Thanks for that TC1 So the bars are ok then.

Oddly enough, I'm not seeing any connection lines between the controller and the thermostat.



Does that confirm my suspicion that both devices are not communicating with each other?

Also, the little dot besides the blue bar of the controller is flashing blue. What does that indicate?

zguy

Maybe the device has started a join, but was reset before it could finish. To restart the join follow these steps (without removing any device anywhere!)

1. In either the plugin (bridge maintenance) or Phoscon start a search for new devices
2. Reset the thermostat (I suppose this is described in the user manual)
3. Check the device in deCONZ, does both coordinator and thermostat show a regular blue dot?
4. Try to manually control the thermostat during this process. This is most important for battery controlled devices, but might even help for your thermostat
5. Check if a read of the basic cluster now works, also try for example a read on Temperature measurement

If this works post the image on github for the basic cluster?

*edit* a blue blinking dot is indicating the device is actually communicating, if it is red, it means coordinator tries to communicate to the device, but cannot get a response. What is the distance between conbee and thermostat?

Wim

[TC1]

Thanks for that TC1 So the bars are ok then.

Oddly enough, I'm not seeing any connection lines between the controller and the thermostat.



Does that confirm my suspicion that both devices are not communicating with each other?

Also, the little dot besides the blue bar of the controller is flashing blue. What does that indicate?

Correct, if there's no connection line between the devices (or it's not green) that usually indicates a communication problem. Part of a reliable Z-wave or Zigbee network design is building out a sufficient mesh, ie, a group of devices within a certain physical distance of each other so that they can route information between the nodes. If you look at the picture I posted you'll see that I have a number of devices that provide various routes in case one goes offline.

And yes, the blue blinking dot indicates attempts at communication.

And as Wim indicated, there's probably not full support for that model thermostat (yet). The fact it only has a node number on that map and not a name (like "Configuration Tool" on your controller) usually means deconz doesn't know what it is.

[zguy]

Thanks for that TC1 So the bars are ok then.

Oddly enough, I'm not seeing any connection lines between the controller and the thermostat.



Does that confirm my suspicion that both devices are not communicating with each other?

Also, the little dot besides the blue bar of the controller is flashing blue. What does that indicate?

[TC1]

zguy you're misinterpreting what those colors indicate.

On the deconz zigbee connection map, a blue bar indicates the network controller. In general there is usually only one.
Yellow indicates a routing node, these are usually devices that are always powered on.
Gray indicates endpoint nodes, these are usually battery powered devices. Since they "sleep' until they are ready to send data, they can not be
routers.

The strength of the signal connection is indicated by the color of the interconnecting lines. They vary from green to yellow to red (or none).

[zguy]

It appears the clusters (now that I know what and where they are) can't be read. Hitting the read buttons in the clusters doesn't do any thing on the thermostat.





The left bar is always yellow and the light right beside always grey on the thermostat. That's different from the RaspBee above on which the left bar is always blue and and the light is flashing blue. On the RaspBee I get responses when hitting the clusters read button.

I'm beginning to think there is a communication issue.

[w.vuyk]

They will want to see all the clusters, especially the basic cluster. Do not forget to do a read on the cluster? We'll see what happens from here