Plugin feature suggestion

[mterry63]

Hello SteveMSJ ,

Thanks for the great plugin. I'm starting to dig into the new logging features, they are a great addition.

I was thinking yesterday that I need a HomeSeer Battery API, and then I thought your plugin is essentially just that. Would it be possible to add a feature to track "user defined" battery devices as well as the HS defined devices? I have a weather station that represents the battery devices as "1" (Good) or "0" (Needs replacement). It would be great to get them in the plugin for tracking. Maybe the same for monitoring my tablet batteries which I do via MQTT. They are usually on AC power, but a notfication if the battery drains would be nice.

Just a thought. Keep up the great work.

[SteveMSJ]

Hello SteveMSJ ,

Thanks for the great plugin. I'm starting to dig into the new logging features, they are a great addition.

I was thinking yesterday that I need a HomeSeer Battery API, and then I thought your plugin is essentially just that. Would it be possible to add a feature to track "user defined" battery devices as well as the HS defined devices? I have a weather station that represents the battery devices as "1" (Good) or "0" (Needs replacement). It would be great to get them in the plugin for tracking. Maybe the same for monitoring my tablet batteries which I do via MQTT. They are usually on AC power, but a notfication if the battery drains would be nice.

Just a thought. Keep up the great work.

You should be able to monitor most battery devices in SDJ-Health if they are represented by HS devices. It doesn't matter whether they are owned by a plug-in or are virtual devices. The pi expects the battery device to be a child/feature of a device, which most are, especially in HS4. If you give me more information about how your weather station is represented in HomeSeer I can probably show you how to do it. As far as the battery values go, you can set a scale in the pi for a device so, in your case, you could make 1 appear as 100% and 0 as 0%.

Similar for your tablet batteries if they are represented in HS as devices by means of MQTT.

Steve

[mterry63]

Thanks Steve. I went through the documentation again today, but I can't get the plugin to recognize my weather station's battery devices as "batteries". I'm not sure exactly what the plugin is looking for. The devices are created by the mcsMQTT plugin and have the interface mcsMQTT and device string of MQTT_Receive. I'm using HS3 and as for child status, using Jon00's device viewer utility I can see that Relationship value is 0 and Relationship status is "Not Set". If I compare to a Z-wave battery device the plugin recognizes/monitors, it has Relationship value 4, Relationship status "Child".

I'm not sure I can influence that relationship. Any suggestions are appreciated.

[TC1]

Make sure the HS Device Type String = Battery on the battery child device in order for the Health plugin to pick it up as a battery.

[SteveMSJ]

Thanks Steve. I went through the documentation again today, but I can't get the plugin to recognize my weather station's battery devices as "batteries". I'm not sure exactly what the plugin is looking for. The devices are created by the mcsMQTT plugin and have the interface mcsMQTT and device string of MQTT_Receive. I'm using HS3 and as for child status, using Jon00's device viewer utility I can see that Relationship value is 0 and Relationship status is "Not Set". If I compare to a Z-wave battery device the plugin recognizes/monitors, it has Relationship value 4, Relationship status "Child".

I'm not sure I can influence that relationship. Any suggestions are appreciated.

Most battery devices in HS are child/features of a parent device, and that is what SDJ-Health is looking for. HS4 is more rigorously enforcing this grouping which not all plug-ins adhere to in HS3. From what you are saying the plug-in that is interfacing with your Weather Station isn't creating a group of devices in HS with the normal Parent Child/Feature relationships. Are there a number of standalone devices created, such as Temperature, Wind Speed, plus the Battery device?

I have a weather station, in fact I use to have two at different locations. These use the CumulusMX weather program and are interfaced with HS using my own script which creates a Parent/Children group of devices in HS for each weather station. Jon00 publishes a script that does this very well. The only reason I developed my own was because I had two weather stations and I think Jon00's script was for a single station. In my case the group of devices representing a weather station looks like below:


My Weather station doesn't provide battery information.

If the devices for your weather station aren't setup with proper relationships to form a group, you can do this manually using Jon00's Device Grouping utility. You would need to pick a suitable device to be the parent, or create a virtual device to be the parent, and set all the other devices as children. I would recommend backing everything up before trying this in case it causes any problems.

Once the battery device is a child in a group the second thing you would need to do is what TC1 has stated in the message above. For the purposes of identifying battery devices SDJ-Health looks at the 'Device Type (string)' to see if it contains the word 'battery'. It purposefully uses this property because it is user editable, so you can manually add the word 'battery' to it if the pi that owns the device hasn't, or if it is a virtual device that you have created yourself. Below is a typical Z-Wave battery device. The text in the box is editable.


This is used purely to include the device in the list of available battery devices for selection within SDJ-Health. Once you have selected it you could change the 'Device Type (string)' back to its original text, although this is unlikely to be necessary.

For your weather station you would select the battery device in the list of 'Devices Requiring Activity Monitoring'. SDJ-Health will then create a monitoring child for the device which, in addition to monitoring the battery levels, can monitor the activity of all the devices in the group representing the weather station. If the devices stop updating for the configured period of time then SDJ-Health would alert you. So, any breakdown of communication between the weather station and HS, not just dead batteries, can raise an alert.

As well as globally setting parameters you can override any parameters for individual devices. If your weather station battery device only has two values 0 and 1 then I would set the scale (Battery Factor) for that device to 100 so the monitoring child will show the battery value as 0% or 100%. You click on the monitoring child and then the SDJ-Health tab to configure a specific device different to the global settings.

I hope this helps but please ask more questions if anything is unclear or your weather station is represented in a completely different way.

Steve

[mterry63]

Steve, your understanding is spot on, all the devices are just individual devices, not the parent/child relationship of a battery Z-wave device, for example. Now that I have the information required to understand how the plugin identifies a battery device, I can test the changes you mention. I am expecting the "not reporting" function to be the best tool I have for dead batteries. I already see that my motion sensors change to "replace battery" months before actually needing to replace the battery, so I wait until they stop reporting.

I would suggest adding the above paragraph about how the plugin identifies battery devices into the documentation of your excellent plugin. Thanks, I will report back the results.

[SteveMSJ]

I would suggest adding the above paragraph about how the plugin identifies battery devices into the documentation of your excellent plugin. Thanks, I will report back the results.

Yes, I should probably add a section in the guide to make this clearer. It is explained in various threads but or course they rapidly drop down the list and quite often become out of date anyway. The plug-in originally was written for Z-Wave devices but has continually been expanded to try and cope with as many variations of devices as possible. I have to rely on feedback from users for interfaces that I don't have and therefore writing a definitive guide is tricky. A better explanation of the basics would be a good idea. When I have some time....

Steve

[SteveMSJ]

At a slight tangent, but related to my weather station, for devices that don't have or display battery information I use the 'General Devices' section of SDJ-Health to know if a problem has developed, e.g. the station has stopped communicating. SDJ-Health is checking the activity of all the devices making up the weather station and my daily report will alert me if communication has stopped. See extract below of the part of the report relating to my weather station.

[mterry63]

Steve, I was able to create a parent device for the 3 battery devices reported by the mcsMQTT plugin. Thankfully mcsMQTT had that functionality built in, I just didn't realize it. Now 2 of the 3 are correctly monitored in SDJ-Health but the 3rd just seems to be stubborn. Looking at the device it has "Battery" in the device type string, reports that it is a child of the newly created root device, and is checked in the "Monitor Activity" section of SDJ-Health, but no health device has appeared.

To be fair, originally mcsMQTT was reporting the value as a voltage instead of percentage (1.4) but I modified the expression in that plugin to report as a percentage using the expression round($$PAYLOAD: * 0.666666667 * 100,0). Now the value reports as 93. No health device. In the log when SDJ-Health starts up I get this error:

ERROR - Failed to add Parent device #1906 of battery device #1901 to list.

But the battery device without the health device is reference number 1899, not 1901. 1906 is the parent of all 3. 1901 is reporting health correctly. Not sure what the issue is. What would you recommend?

Thanks for the general monitor tip, I plan to use that as well. I'm really pleased with how multi-functional your plugin has become, I've used it since the Z-wave only days.

[SteveMSJ]

Steve, I was able to create a parent device for the 3 battery devices reported by the mcsMQTT plugin. Thankfully mcsMQTT had that functionality built in, I just didn't realize it. Now 2 of the 3 are correctly monitored in SDJ-Health but the 3rd just seems to be stubborn. Looking at the device it has "Battery" in the device type string, reports that it is a child of the newly created root device, and is checked in the "Monitor Activity" section of SDJ-Health, but no health device has appeared.

To be fair, originally mcsMQTT was reporting the value as a voltage instead of percentage (1.4) but I modified the expression in that plugin to report as a percentage using the expression round($$PAYLOAD: * 0.666666667 * 100,0). Now the value reports as 93. No health device. In the log when SDJ-Health starts up I get this error:

ERROR - Failed to add Parent device #1906 of battery device #1901 to list.

But the battery device without the health device is reference number 1899, not 1901. 1906 is the parent of all 3. 1901 is reporting health correctly. Not sure what the issue is. What would you recommend?

Thanks for the general monitor tip, I plan to use that as well. I'm really pleased with how multi-functional your plugin has become, I've used it since the Z-wave only days.

Hi,

1906 is the parent of all 3

Are you saying that you have grouped the three battery devices together with the same parent?
That would certainly confuse the pi as it only expects a physical device to have one battery device. I'm not sure what the consequences would be, without delving back into the code. It may or not work. I would have expected either all three to work or none to work, not two out of three as you are observing.

Conventionally a physical device would be represented by a parent and a number of child/features one of which would be the battery for that physical device. If you are defining the relationship of a group of devices I would stick to that convention.

Steve

[SteveMSJ]

Hi,

1906 is the parent of all 3

Are you saying that you have grouped the three battery devices together with the same parent?
That would certainly confuse the pi as it only expects a physical device to have one battery device. I'm not sure what the consequences would be, without delving back into the code. It may or not work. I would have expected either all three to work or none to work, not two out of three as you are observing.

Conventionally a physical device would be represented by a parent and a number of child/features one of which would be the battery for that physical device. If you are defining the relationship of a group of devices I would stick to that convention.

Steve

Having had a quick delve into my code, it is as I thought, I use the parent as the reference for the 'Device'. Whilst the pi is monitoring the battery levels it is also monitoring the device as a whole, i.e. wake-up of the node, activity of all the devices representing the physical device. So, having more than one battery child with the same parent would definitely confuse things. I should probably add some checking in the pi to warn when this is encountered, it just has never come up before.

The error message you note:

ERROR - Failed to add Parent device #1906 of battery device #1901 to list.

occurs when you enter the Battery Config page and the pi is building the list of battery devices. The error is due to trying to add a child to the list when the parent already exists in the list. If you have three battery childs with the same parent I would have thought you would get two of these errors and only one device would appear in the list. However, if devices had already been selected before additional relationships were created it might retain more than one in the list. Either way it will confuse the pi if you manage to create more than one monitoring device with the same parent.

If you set LogLevel=2 and then call up the Battery Config Page, you will get a lot of debug messages in the log which might help pin down what is going on. However, that's not going to be much help as the solution will still be to only have one battery child for any parent.

Steve

[mterry63]

Thanks Steve, your explanation makes sense. I'll reconfigure so each battery device has it's own parent and see how that works.

[SteveMSJ]

Thanks Steve, your explanation makes sense. I'll reconfigure so each battery device has it's own parent and see how that works.

👍