Thermostats disconnecting and reconnecting every 8 hours

In my installation several thermostat are shown as disconnected from the ZigBee network after 6 hours, to be shown as reconnected again after two hours, without anyone disconnecting or reconnecting the actual devices, to be disconnected again after another six hours.

A view I have set up in the dashboard shows it like this:

A spot check reveals that the thermostats themselves still seem to be thinking they’re connected to the network. In any event, they show the ‘connected’ icon on their displays during those times.

Opening the network and resetting the devices usually reconnects them to the ZigBee network right away. Instead of resetting the device I can remove and re-attach the batteries, and the devices will also reconnect to the net. I did this a number of times before I detected that they were reconnected after two hours. That’s why some of the gaps in the diagrams might appear to be shorter than two hours.

Five of the six thermostats that follow this pattern appear to do so synchronously, but this might be due to the fact that I initially connected them all at about the same time.

I don’t know how long this has been going on. I only detected the pattern after I wrote a magic which turned on a lamp whenever a device was disconnected.

All devices are connected through IKEA repeaters, but some other devices also connected through IKEA repeaters do not follow that pattern. The devices for which there no data is shown are connected but the time stamps of the respective log entries lie before the beginning of the time slice shown in the diagram. (That might be another issue: the diagram does not show the correct values in that case.)

Obviously, that’s not reasonable behaviour for a system which is supposed to manage the heating of my home on a time grain of - say - half an hour. I haven’t found out yet what happens to any commands sent to the thermostats during their off times.

During the whole episode one temperature sensor also was repeatedly disconnected; I haven’t found out yet whether it follows a similar pattern.

All thermostats are of the type H1 by Ubisys. They all have the same firmware level. The repeaters are all IKEA and all have the same firmware level as well.

What to do? How do I retrieve more information?

The temperature sensor mentioned above has just disconnected. It was last connected today from 09:25:45 to 15:26:08, according to the log.

Hmm, so nymea will mark sleepy devices as disconnected if they don’t send anything within a 6 hours timeframe. This looks like it might be the case here.

For a start, please verify that those thermostats are indeed sleepy devices. You can check that by opening the ZigBee system settings and verifying that there is a sleepy icon shown for the thermostats. If that’s the case, I’m fairly positive this is what we’re seeing here…

If not, other reasons may be that it fails to reply to a request… In that case you should see something in the logs about it… Please enable the “ZigbeeNetwork” debug logs and then let’s evaluate them when it happens next time.

Thank you, Michael.

Your hints have me allowed to do a bit more research, even though the problem has not occurred since. The mechanism leading to the devices being disconnected might be indeed what you say:

  • All thermostats and sensors are indeed marked as ‘sleeping’ in the ZigBee device list.
  • The thermostats (and the sensor) that are thrown out have not reported an actual temperature for more than a day (4th of June in most cases)
  • The thermostats and sensors reported as connected have continually reported values for the current temperature.

However, this would not explain why the devices are suddenly recognized as being connected after two hours, I think.

Even stranger:

  • I don’t see why those thermostats don’t report any values for the actual temperature.
  • Other devices in the same room still report (small) temperature differences.
  • All of those thermostats regularly reported the actual temperature until about the fourth of June.
  • I can’t see why they don’t do so any more.

That reminds me a bit of the still unsolved issue why my Airmonitors (and other temperature sensors as well) sometimes reported the humidity or the air quality and sometimes did not, but mostly didn’t, after a while.

The following shows the readings for the thermostat and two different temperature sensors in one of the affected rooms:

You can see even at that scale that for some time the thermostat was live and reported the current temperature. It then dropped in and out of service while the other sensors still were live. All shown devices are connected through the same repeater.

mhm… ok. it’s indeed strange that they stopped reporting the actual temperature… Also strange that it seems to have happened at the same time for all of them. Perhaps something did change somewhere but no idea where to point you at… Could it be they are only reporting it when it’s low enough so the thermostats will actually do something and now that it got really warm, they entered a power save mode or something?

About them being marked as disconnected, that’s really just an internal flag in nymea, it doesn’t actually mean anything besides the fact that nymea didn’t get any data from them in more than 6 hours. It’s not like they are being kicked out from the network. As soon as nymea will receive a data packet again, they will be marked as connected again. Still, I don’t like having devices being marked as disconnected in my system either, so I agree that it makes sense to investigate why they’re not sending anything and fix that, or, if they really won’t send anything during summertime due to some energy saving mode, perhaps add a workaround to increase the 6h timeout to something more reasonable for those devices. The thing with sleepy devices is, that we can’t “ping” them… They need to wake up on their own and send something, otherwise the coordinator (nymea in this case) has no way of knowing whether they are still around or not - hence the 6h timeout which we felt like seems a reasonable time frame for such devices.

Also, reading the code for the zigbee thermostat handlers, I see that nymea does not explicitly configure the attribute reporting for the measured temperature… Perhaps we could try to add that and see how they behave with that… Not that I’d have high hopes for that, seeing that it did work previously without that explicit call, but who knows… I’d need you to send me the node descriptor for the device to do so. When the “Zigbee” debug logs are enabled, and you restart nymead, it will print the node descriptors for all zigbee devices to the log.

The problem affects only 6 of my 10 thermostats. Here are the diagrams for another room. It has two thermostats, both still reporting current temperatures and both continually online:

The timestamp 02.06.23 - 19:52:46 refers to a system start. The system protocol does not show a system stopped entry just before that, so I presume that was when I had to restart the Raspi as it had become unresponsive.

However, it’s not new to me that some of the thermostats stopped reporting actual temperatures. I seem to remember that some did that before.

I worry about the disconnected state because I think nymea won’t send any commands to a device marked as disconnected. How am I going to change the target temperature of my thermostats in that case?

Edit: I just had this thought: you say you can’t ping the ZigBee devices. Yet I clearly remember Home Assistant doing just that: it sent an ‘identify’ command to a thermostat and it waved a flag when it received the command. The device actually shows a pictogram of a flag. That was a really helpful function.

One of thermostats has been disconnected again, 6 hours after having been last connected.
The log has this to say:

I | ZigbeeNetwork: ZigbeeNode(0x3b1c, 00:1F:EE:00:00:00:99:43, ubisys (0x10f2), H1, End device, RxOn:false) has been seen the last time “06:00:27” ago.
W | ZigbeeNode: Reachable changed ZigbeeNode(0x3b1c, 00:1F:EE:00:00:00:99:43, ubisys (0x10f2), H1, End device, RxOn:false) false

The device in question (0x3b1c) has been mentioned each minute with ‘has been seen the last time hh:mm:ss ago’. It has been mentioned exactly once with ‘reachable changed’. Do you need more of the log? I have logged some 550 lines during perhaps ten or fifteen minutes. None of them seems to have a time stamp.

The device in question (phHeizung, 0x3b1c) says it’s still connected. Nymea says it’s not connected. Changing the target temperature either in Nymea or in the device has no effect. They’re not speaking to each other.

I can change the target temperature in nymea for another thermostat which then shows the new value. I can also change the target temperature in that other thermostat and the new value shows in nymea.

I have restarted nymea. What part of the log do you need? The complete log is about 1MB in size. I could transfer it with wetransfer or something like that.

Only the node descriptor for this particular device. It should look similar to the paste in this post: Zigbee device request - #3 by s05

This is the signature for one of the thermostat that still report the current temperature and that are not disconnected after six hours:

Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: —> ZigbeeNode(0xd6d5, 00:1F:EE:00:00:00:99:60, ubisys (0x10f2), H1, End device, RxOn:false)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Manufacturer: “ubisys”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Model: “H1”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Version: “1.1.10”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: NodeDescriptor(ZigbeeDeviceProfile::NodeTypeEndDevice)
Jun 6 18:44:51 localhost nymead[9887]: Complex descriptor available: false
Jun 6 18:44:51 localhost nymead[9887]: User descriptor available: false
Jun 6 18:44:51 localhost nymead[9887]: ZigbeeDeviceProfile::FrequencyBand2400Mhz
Jun 6 18:44:51 localhost nymead[9887]: MacCapabilities(“0x80”)
Jun 6 18:44:51 localhost nymead[9887]: Alternate PAN Coordinator: false
Jun 6 18:44:51 localhost nymead[9887]: ZigbeeDeviceProfile::DeviceTypeReducedFunction
Jun 6 18:44:51 localhost nymead[9887]: Power source main power: false
Jun 6 18:44:51 localhost nymead[9887]: Receiver on when idle: false
Jun 6 18:44:51 localhost nymead[9887]: Security capability: false
Jun 6 18:44:51 localhost nymead[9887]: Allocate address: true
Jun 6 18:44:51 localhost nymead[9887]: Manufacturer code: “0x10f2”(4338)
Jun 6 18:44:51 localhost nymead[9887]: Maximum buffer size: 127
Jun 6 18:44:51 localhost nymead[9887]: Maximum RX size: 82
Jun 6 18:44:51 localhost nymead[9887]: Maximum TX size: 82
Jun 6 18:44:51 localhost nymead[9887]: ServerMask(“0x2c00”)
Jun 6 18:44:51 localhost nymead[9887]: Primary trust center: false
Jun 6 18:44:51 localhost nymead[9887]: Backup trust center: false
Jun 6 18:44:51 localhost nymead[9887]: Primary binding cache: false
Jun 6 18:44:51 localhost nymead[9887]: Backup binding cache: false
Jun 6 18:44:51 localhost nymead[9887]: Primary discovery cache: false
Jun 6 18:44:51 localhost nymead[9887]: Backup discovery cache: false
Jun 6 18:44:51 localhost nymead[9887]: Network manager: false
Jun 6 18:44:51 localhost nymead[9887]: DescriptorCapabilities(“0x00”)
Jun 6 18:44:51 localhost nymead[9887]: Extended active endpoint list available: false
Jun 6 18:44:51 localhost nymead[9887]: Extended simple descriptor list available: false
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: PowerDescriptor(“0x10”)
Jun 6 18:44:51 localhost nymead[9887]: Power mode: ZigbeeDeviceProfile::PowerModeAlwaysOn
Jun 6 18:44:51 localhost nymead[9887]: Available power sources: (ZigbeeDeviceProfile::PowerSourcePermanentMainSupply)
Jun 6 18:44:51 localhost nymead[9887]: Power source: ZigbeeDeviceProfile::PowerSourcePermanentMainSupply
Jun 6 18:44:51 localhost nymead[9887]: Power level: ZigbeeDeviceProfile::PowerLevelFull
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Endpoints: 1
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeNodeEndpoint(0x01, Zigbee::ZigbeeProfileHomeAutomation, Zigbee::HomeAutomationDeviceThermostat)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Input clusters:
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0004, Groups, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0005, Scenes, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0020, PollControl, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0003, Identify, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0201, Thermostat, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0008, ZigbeeDataType(Unsigned 8-bit integer, 0x00))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0014, ZigbeeDataType(Signed 16-bit integer, 0x40 0x06))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0012, ZigbeeDataType(Signed 16-bit integer, 0x78 0x05))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0000, ZigbeeDataType(Signed 16-bit integer, 0x92 0x09))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x001c, ZigbeeDataType(8-bit enumeration, 0x04))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0000, Basic, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0004, ZigbeeDataType(Character string, ubisys))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x4000, ZigbeeDataType(Character string, 1.1.10))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0005, ZigbeeDataType(Character string, H1))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0xfc57, Unknown, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0001, PowerConfiguration, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0020, ZigbeeDataType(Unsigned 8-bit integer, 0x23))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0021, ZigbeeDataType(Unsigned 8-bit integer, 0xc8))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x000a, Time, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Output clusters:
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0019, OtaUpgrade, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0406, OccupancySensing, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0003, Identify, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0201, Thermostat, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0405, RelativeHumidityMeasurement, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0402, TemperatureMeasurement, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x000a, Time, Client)

There seem to be two similar entries for the same device, with a different task# and the heading Zigbee: instead of ZigbeeNetwork:

This is the same entry type for the device instance which was disconnected just before restarting nymea:

Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: —> ZigbeeNode(0x3b1c, 00:1F:EE:00:00:00:99:43, ubisys (0x10f2), H1, End device, RxOn:false)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Manufacturer: “ubisys”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Model: “H1”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Version: “1.1.10”
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: NodeDescriptor(ZigbeeDeviceProfile::NodeTypeEndDevice)
Jun 6 18:44:51 localhost nymead[9887]: Complex descriptor available: false
Jun 6 18:44:51 localhost nymead[9887]: User descriptor available: false
Jun 6 18:44:51 localhost nymead[9887]: ZigbeeDeviceProfile::FrequencyBand2400Mhz
Jun 6 18:44:51 localhost nymead[9887]: MacCapabilities(“0x80”)
Jun 6 18:44:51 localhost nymead[9887]: Alternate PAN Coordinator: false
Jun 6 18:44:51 localhost nymead[9887]: ZigbeeDeviceProfile::DeviceTypeReducedFunction
Jun 6 18:44:51 localhost nymead[9887]: Power source main power: false
Jun 6 18:44:51 localhost nymead[9887]: Receiver on when idle: false
Jun 6 18:44:51 localhost nymead[9887]: Security capability: false
Jun 6 18:44:51 localhost nymead[9887]: Allocate address: true
Jun 6 18:44:51 localhost nymead[9887]: Manufacturer code: “0x10f2”(4338)
Jun 6 18:44:51 localhost nymead[9887]: Maximum buffer size: 127
Jun 6 18:44:51 localhost nymead[9887]: Maximum RX size: 82
Jun 6 18:44:51 localhost nymead[9887]: Maximum TX size: 82
Jun 6 18:44:51 localhost nymead[9887]: ServerMask(“0x2c00”)
Jun 6 18:44:51 localhost nymead[9887]: Primary trust center: false
Jun 6 18:44:51 localhost nymead[9887]: Backup trust center: false
Jun 6 18:44:51 localhost nymead[9887]: Primary binding cache: false
Jun 6 18:44:51 localhost nymead[9887]: Backup binding cache: false
Jun 6 18:44:51 localhost nymead[9887]: Primary discovery cache: false
Jun 6 18:44:51 localhost nymead[9887]: Backup discovery cache: false
Jun 6 18:44:51 localhost nymead[9887]: Network manager: false
Jun 6 18:44:51 localhost nymead[9887]: DescriptorCapabilities(“0x00”)
Jun 6 18:44:51 localhost nymead[9887]: Extended active endpoint list available: false
Jun 6 18:44:51 localhost nymead[9887]: Extended simple descriptor list available: false
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: PowerDescriptor(“0x10”)
Jun 6 18:44:51 localhost nymead[9887]: Power mode: ZigbeeDeviceProfile::PowerModeAlwaysOn
Jun 6 18:44:51 localhost nymead[9887]: Available power sources: (ZigbeeDeviceProfile::PowerSourcePermanentMainSupply)
Jun 6 18:44:51 localhost nymead[9887]: Power source: ZigbeeDeviceProfile::PowerSourcePermanentMainSupply
Jun 6 18:44:51 localhost nymead[9887]: Power level: ZigbeeDeviceProfile::PowerLevelFull
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Endpoints: 1
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeNodeEndpoint(0x01, Zigbee::ZigbeeProfileHomeAutomation, Zigbee::HomeAutomationDeviceThermostat)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Input clusters:
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0004, Groups, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0005, Scenes, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0020, PollControl, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0003, Identify, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0201, Thermostat, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0008, ZigbeeDataType(Unsigned 8-bit integer, 0x00))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0014, ZigbeeDataType(Signed 16-bit integer, 0x40 0x06))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0012, ZigbeeDataType(Signed 16-bit integer, 0x78 0x05))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0000, ZigbeeDataType(Signed 16-bit integer, 0x60 0x09))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x001c, ZigbeeDataType(8-bit enumeration, 0x04))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0000, Basic, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0004, ZigbeeDataType(Character string, ubisys))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x4000, ZigbeeDataType(Character string, 1.1.10))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0005, ZigbeeDataType(Character string, H1))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0xfc57, Unknown, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0001, PowerConfiguration, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0020, ZigbeeDataType(Unsigned 8-bit integer, 0x23))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeClusterAttribute(0x0021, ZigbeeDataType(Unsigned 8-bit integer, 0xc8))
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x000a, Time, Server)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: Output clusters:
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0019, OtaUpgrade, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0406, OccupancySensing, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0003, Identify, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0201, Thermostat, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0405, RelativeHumidityMeasurement, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x0402, TemperatureMeasurement, Client)
Jun 6 18:44:51 localhost nymead[9887]: D | ZigbeeNetwork: - ZigbeeCluster(0x000a, Time, Client)

Is the thermostat marked as connected again if you press a button on it? e.g if you change the setpoint temperature using the buttons on the device itself.

Edit: Sorry, I missed that you already tried that…

Well, if that’s not working either, in other words, if they actually lose the connection, then I suppose next step would be to see if the link is good enough? Didn’t you remove some repeaters recently?

I did not remove any of the repeaters. I moved one of the repeaters closer to a thermostat, but the thermostat did not use that repeater before and it did not use it after the move, either. That thermostat is not affected by the issue at hand.

In the last few days I have tried reconnecting the thermostats in different ways:

  • Delete thing from nymea and add again by resetting the thermostat (following manufacturer’s procedure)
  • Resetting the thermostat
  • Removing batteries from thermostat and adding again
    In each case opening the ZigBee network for new devices, of course.
    All were immediately successful and the devices kept being connected for six hours and then disconnected.

After a day of repeatedly reanimating the thermostats I detected by coincidence that the connection restored itself after a while (two hours) and then the device worked as it did before until it dropped again after six hours.

As I said before, the device still showed the network icon. They didn’t use to do that when the actual link was weak or when the connecting router (bulb or power plug) stopped working.

The issue was, unfortunately, even more confused by a blackout in one floor of the house, caused by a blown fuse. This caused all the devices which were connected to repeaters on that floor to re-route their connection and later back again, and not all devices were immediately successful. Unfortunately, I did not keep any detailed notes about that incident. I did not think that it was related to the case of the dropped connections, but I might be mistaken. Looking at the ZigBee network map it seems that all affected devices now are connected via repeaters that lost power because of that blackout. The wiring of my home is not very intuitive. However, the repeaters themselves look completely innocent.

I traced the moment in the log file when the thermostat came back to life after it has been disconnected for 2 hours (ZigbeeNetwork and ZigBee set to debug). This is an extract.

Jun 7 12:20:13 localhost nymead[10080]: D | ZigbeeNetwork: ZigbeeNode(0x3b1c, 00:1F:EE:00:00:00:99:43, ubisys (0x10f2), H1, End device, RxOn:false) has been seen the last time “07:59:21” ago.
Jun 7 12:21:13 localhost nymead[10080]: D | ZigbeeNetwork: Evaluating reachable state of nodes…
Jun 7 12:21:13 localhost nymead[10080]: D | ZigbeeNetwork: ZigbeeNode(0x3b1c, 00:1F:EE:00:00:00:99:43, ubisys (0x10f2), H1, End device, RxOn:false) has been seen the last time “00:00:18” ago.
Jun 7 12:21:47 localhost nymead[10080]: I | NetworkDeviceDiscovery: Starting network device discovery …
Jun 7 12:22:00 localhost nymead[10080]: D | ZigbeeNetwork: Network request sent successfully to device Request(ID:157, Zigbee::ZigbeeProfileHomeAutomation, ZigbeeClusterLibrary::ClusterIdOtaUpgrade, NWK address:“0xecd2”, Destination EP:“0x01”, Source EP:“0x01”, Radius:0, QFlagsZigbee::ZigbeeTxOption(ZigbeeTxOptionAckTransmission), “0x09 0xa0 0x00 0x00 0x64”)
Jun 7 12:22:07 localhost nymead[10080]: I | NetworkDeviceDiscovery: Discovery finished. Found 8 network devices in “00:20.006”
Jun 7 12:22:13 localhost nymead[10080]: D | ZigbeeNetwork: Evaluating reachable state of nodes…
Jun 7 12:24:34 localhost nymead[10080]: D | ZigbeeNetwork: Received unhandled broadcast ZDO indication APSDE-DATA.indication(NWK address:“0xfffd”, Destination EP:“0x00”, Source EP:“0x00”, Source NWK address:“0x5854”, Zigbee::ZigbeeProfileDevice, ZigbeeDeviceProfile::MatchDescriptorsRequest, ASDU: “0x04 0xfd 0xff 0x04 0x01 0x01 0x19 0x00 0x00”, LQI: 255, RSSI: -55dBm)

The extract shows two consecutive items about the thermostat 0x3b1c. First, is has been seen 07:59:21 ago. In the next item it has been seen 00:00:18 ago. No other information is shown in the log, but clearly the timeout period has been reset from eight hours to zero.

I don’t know if the entries following 12:21:47 are relevant in this context. They simply follow a group of messages stating that such-and-such device has been seen last (a time span) ago.

A side remark. Reading the log files would be greatly simplified if each kind of entry was clearly marked by an entry type indicator, with each entry type uniquely identified by some - well - identifier. This would really simplify filtering and parsing the lines.

If those devices send something every 8hours, we could increase the timeout from 6 to, say, 10 hours… The thing that makes me wonder though… you say, that while it is marked as disconnected in nymea, when you press a button on the thermostat, it does not send anything to nymea… I find that quite strange, it really should report a change to the setpoint temperature right away to the coordinator - or well, at latest after 2 minutes as per attribute reporting configuration.

How and where can I see whether the devices send something, and what they send? The logs I have been watching so far do not contain that data.

At the moment, I have the suspicion that nymea:core ignores what the things are sending after six hours. I don’t know why they are re-activated after eight hours, either.

Well, you can enable the ZigbeeCluster logs which would show all the packets sent between clusters. But that will print a whole lot of stuff… you’d have to manually enable that in the nymead.conf file though as there isn’t a UI category in the debug interface for that.

There’s also a last seen timestamp available for each device. You can find that in the Network map when you select a device. This timestamp is updated on every data packet that is received from a device, regardless of what packet type it is. This is the timestamp that’s also used to calculate the connected state. So it probably won’t provide much more information than you already got from the logs.

I’m having a hard time to believe that nymea would ignore some packets from a device. That would be a serious bug which I believe would have shown up much more often already…

I still think that for some reason those thermostats will only send something every 8hours when going into some sort of battery saving summer mode. The 6 hours timeout nymea is using is an arbitrary number and not defined in the ZigBee specification. If the manufacturer of those devices picked 8 hours as this arbitrary number, we’d see exactly the behavior we see now.

I have some more information, but nothing conclusive, so far:

  • On one of the thermostats running through the 8 hour cycle I tried changing the target temperature while the device was reported as ‘connected’. I don’t know why I did not think earlier of that. The result:
    • changing the target temperature on the device with its wheel did indeed change the target temperature shown on its device. The changed target temperature did not, however, appear in nymea.
    • On the other hand, changing the target temperature in nymea:app was sent to the thermostat and shown on its display.
    • The device ‘disconnected’ again, six hour after I had changed its target temperature.
  • I removed one of the other 8 hour thermostats from the network and bound it to the network again:
    • Open the ZigBee network for new devices
    • remove the thermostat from the ZigBee device list
    • The thermostat immediately began to reset itself to the factory state and initiated pairing with the network again.
    • Since then, that thermostat keeps reporting the current temperature. In this very moment, the ZigBee map says it has been heard from a minute ago.
  • So: detaching the thermostats from the network and adding them again makes them behave themselves again. I don’t like doing that as I lose magic whenever I do that, and I have to redo that magic again and again.
  • Merely opening the network and pairing the thermostat again without deleting it first from the network sometimes helps, but not in this case.

The thermostats are not the only devices where information they were supposed to send was not shown or processed by nymea.
Please remember the Lumi Airmonitors I tried using with nymea earlier this year. They mostly but not always reported the current temperature, started reporting the humidity but stopped doing so after a while and reported once or twice the air quality and then ceased doing that, too.

I then installed another set of temperature sensors. They keep on reporting the temperature fairly well; some of them report humidity values, others don’t, even when they’re all the same make.

One of those sensors also quit reporting anything at about the same time as the thermostats did, but it was not re-awakened after eight hours. Removing and adding it again to the network made it behave well again. Anyway, it keeps on reporting temperature and humidity faithfully ever since I restarted it at 11:30.

So, I have at least three different device types by at least two different manufacturers that seem to drop out of service. I don’t think anymore that those are network connectivity issues. I don’t know yet what it might be.

But then, I have two different temperature sensors, several power plugs, lights and switches that run really well. This makes me think that the system itself ought to be fairly robust.

As I wrote before, I changed the target temperature for one of those affected thermostats. Accordingly, it was reported as disconnected later than the other affected thermostats. But - would you believe it - it came back to the disconnected state at the same time as the other ones and now appears to be in step with the others again.

The bottom left graph is the thermostat with the changed target temperature. The bottom right graph is the one I removed from and added to the network again. Its current connected status is ‘on’. The two graphs above the bottom ones are for thermostats with the 6h and 8h intervals.