Spirit thermostat does not properly report battery level

Hi all,

My spirit thermostat showed 5% battery. So I replaced the two AA batteries. I requested a status update, and also sent a few z-wave commands to make sure the thermostat communicates again.
However, the battery level stayed at 5%. Only after I did a sync of the thermostat, the battery level correctly indicated 100%

This happened with three thermostats out of three.

Is there a bug in the driver, or am I supposed to periodically send a z-wave command to make sure Indigo knows the actual battery level?

Thanks!

Mark

I am having a similar problem with Z-Wave Plus Aeotec Radiator Thermostat.
Problem may only have arisen in Indigo 7.5 (certainly only arisen recently in this form although had other problems with these valves)
Valve works well for a while, but nonce battery level stuck at 5% syncing is the only way to get the device to correctly report the battery level again.

Having a potentially related problem with Heltun Qunito devices.
These are brilliant devices in many respects, despite not being specifically defined yet within indigo, except that I keep finding switches 2-5 stop working (e.g. indigo reports switches 2-5 do not support turnon command - switch 1 keep working) and the only solution is to resync the device again.
As I have been moving these devices around a bit as well, it is possible that the problem occurs after the device has been unpowered and powered up again, but not yet sure.

So two questions: -
1) is there a way of re-syncing using a python script (so I don't have to log in to the server), and
2) has Indigo 7.5 introduced a way indigo can 'forget' some of the details of a device, or is this problem more likely the device end?
Both of these are relatively new devices - is there a general issue with more complex devices?

Quite happy to provide more details as the problem re-occurs [no doubt it will ] if this would help.

Indigo only requests a battery update once or twice a day in order to save battery power.

You can force an immediate battery update on a Spirit thermostat by issuing a Raw Z-Wave command. Indigo menu Interfaces > Z-Wave > Send Raw Z-Wave Command... and then selecting your Spirit and setting the payload bytes to 0x80 0x02

There should be need to re-sync.

Thanks Jon. Makes sense. And the raw zwave command is exactly what I needed!

[matt (support)]

1) is there a way of re-syncing using a python script (so I don't have to log in to the server), and

Unfortunately, no. The UI has to start the sync process.

2) has Indigo 7.5 introduced a way indigo can 'forget' some of the details of a device, or is this problem more likely the device end?

Does a re-sync always fix the problem? Check the Event Log for errors Indigo might be reporting for the devices in question. It is possible Indigo is getting confused by the device type information the Z-Stick is reporting and partially disabling some of the devices until the next re-sync.

Both of these are relatively new devices - is there a general issue with more complex devices?

Possibly. The next version of Indigo will have some preliminary support for some Heltun modules, so it might work better (since there will be some device definitions).

Hi Matt, thanks for the quick response. I have been thinking what tests I should run to characterise this problem with thre Heltun Quintos properly, as for me at least it is potentially a significant issue, and I will include catching anything relevant in the log. One objective is to try and trace when the change from working to not working occurs - is it for instance when the Mac or Indigo is restarted. Will probably take me about a week to come back.

Hi Matt,

Does some further tests on the Heltun Quinto issue.

After initial inclusion and syncing the devices works fine.

After stopping and restarting Indigo , the initialisation sequence in Indigo's logfile shows errors for each of my 5 Heltun Quinto devices (2 examples shown below):
Z-Wave Error module 122 included in controller does not match device "Irrigate_VA1-1" type (controller module type: zwCustomType/zwCustomType (4, 24, 0), indigo device type: zwRelayType (4, 24, 0))
Z-Wave Error module 123 included in controller does not match device "Irrigate_GVA1" type (controller module type: zwCustomType/zwCustomType (4, 24, 0), indigo device type: zwRelayType (4, 24, 0))

At this point the device no longer works properly. Of the 5 relays making up the quinto, attempting operate relay one reports no errors (but doesn't switch), and relays 2-5 report errors when you try to switch them, e.g:
Z-Wave Error device "Irrigate_GVA-Test" does not support on command
Z-Wave Error device "Irrigate_GVA-Test" does not support off command

This is only corrected by resyncing the device. Since you cannot resync the device programmatically, this means manual intervention after any restart of Indigo. So far, it would appear that provided Indigo is not restarted, the devices are stable in operation.

Any suggestions, or will this have to wait for the next update of indigo?

[matt (support)]

This sounds very similar to a known issue which I'm still investigating. I should have it fixed in the next major release (very soon), or in a bug fix release after that.

[matt (support)]

Indigo 2021.1.1 is now available and we believe this problem should now be fixed.

Hi Matt,
installed 2021.1.1. Generally gone very smoothly. May now contemplate update my Mac.
Clearly the Qunito now has a proper definition and appears to work OK, although I probably need a few days trial to be sure.

HOWEVER:

It is worth noting that the conversion process of the quinto device from the previous generic definition to the new bespoke definition, as you upgrade to 2021.1 and then resync inserts a new sub-device , the power meter, at the front of the list of 5 relay subdevices within the quinto device - but the identities of the existing sub-devices do not move along. The effect is to assign old device names to different devices one step along the list (e.g. when you intend to switch relay 3 you end up switching relay 2) - which unless you have hardware which is intrinsically safe means that the software could unintentionally drive the wrong action resulting in problems/damage unless you recognise what is going on. It is probably worth letting people know this. I am not aware this problem has ever arisen before as device definitions have been updated. Obviously this affects addressing the devices directly by name, and any link to devices on control pages.

[matt (support)]

Good point. I added the preliminary definitions for the Heltun modules back in 2021.1.0 I think but didn't add it to the announcement since it probably still needs some work. I've gone back and added it to the announcement post along with a note alerting about the devices shifting, and how manual changes may be needed after the re-sync.