I've experienced the COMMLOST condition on very rare occasions. The one time I figured out the cause, the cable was loose. The device.timeleft test handles any unknown conditions that don't send data. I also tested the latest code by pulling the UPS' power plug, and the device's states updated as expected.
1 Like
[UPDATE] Jun 21, 2022 15:25 EDT
V0.1.4 Fixed error introduced in V008: when status not ONLINE device update messages were not processed. Modified logic correcting this error.
2 Likes
Thank you very much for quick update and more importantly, for throwing all this together in the first place!
2 Likes
Hi @arnb,
I just noticed that I was getting warnings in my HE logs saying that a message was received from my laptop but there was no corresponding device with the right DNI to receive the message. Turned out the DNI for my Smart UPS device had a DNI of "null". Looking at the driver it checks the "mac" value in the message and if it does not match the device, it updates it. The message has a mac value of "null" and the IP value contains the mac address.
Has anyone else seen this happen?
I have commented out the section of the code for now (around line 180), as I cannot see how this would work.... if the mac somehow changed, or the UPS was connected to a different host, I would expect the message containing the new mac would not be passed on to the right device on HE, so no automatic update would occur anyway.... Do you also think that section of the code should be removed?
I think I did the same and commented out 179-184.
1 Like
I took a look at that code and it appears to be superfluous, perhaps something I copied from Steve Wright's APC UPS Monitor Driver. The deviceNetworkId field is not used by the remainder of the code.
I'm wondering: other than the UPS does anything else on your system send a message to the laptop's Event Ghost port? Also turning off the debug flag should stop those messages.
So @sburke781 thank you for reporting this issue, and @FriedCheese2006 thank you for confirming the solution. I'll update the code in the near future.
Comment out this code.
// Update DNI if changed
if (msg?.mac && msg.mac != device.deviceNetworkId)
{
if (enableDebug) log.debug "Updating DNI to MAC ${msg.mac}..."
device.deviceNetworkId = msg.mac
}
2 Likes
Yes, I saw this in the other variation of this driver as well I use for an APC connected to a rpi.
The warnings are generated by the HE hub, not the driver. The messages are being sent from my laptop using EventGhost and HE doesn't know where to pass them onto, at least when the DNI is not set correctly. So the debug setting won't stop these warnings from appearing. But that doesn't matter, the update to the driver works.
It's been a while since I looked at this and honestly I forgot how HE figures out where to pass the message for processing.
All good. I have a couple of integrations that use it, including the EcoWitt one I now look after, but it is not a commonly used feature from what I can tell.
1 Like
Is this expected to still work with the latest code on a C8?
When I run the first vbs test (step 8), I get an error in the hub logs.
Package installed, driver and virtual device installed, apcupsd running and com working.
(multiple vbs runs shown because - insanity)
You need to edit the device network id on the virtual device to be in me if those values in the logs, probably the Mac address.
Do I have the wrong driver? It only has a spot for ip address of the host.
I installed the package via HPM.
ETA: checked the SmartUPS v0.1.4 (driver) is the same one on github.
Yes, I believe you do have the right driver. I should explained my suggestion a little better. In the device page where you can set the device name, label, driver, etc, there is a device network id you can edit. You need to set that to one of the identifiers mentioned in the log.
I must be dense. I edited the DNI to the first mac (which is the 10.10.10.2 of my server) and it now throws a java error.
I saw upthread where you all discussed removing a section of the code that checks. By what I'm reading, it should be a superfluous message but the state/status never updates in the device.
I don't think you have done anything wrong. Try turning on the debug logging option to see the information being passed from your PC.
OK, scratch that, I was looking at the wrong mac (I have many and virtuals...)
I had also commented out the line mentioned 179-184.
The onbattery, offbattery vbs work and update the driver state. The smartups still gens the error.
Line 259 is "watts" and apcupsd isn't showing any watts for my UPS. It's an older APC SmartUPS 2200-RM.
That will be a problem. You could try commenting that line out, depending on the impact of not reporting it... I guess you mostly want to know if you are on battery or not...
Yea, don't much care about volts/watts, etc.
On battery, and when the batts/time gets low shutdown the hub.
I already had Powerchute managing the server (which I had to uninstall for apcupsd), I just wanted to roll in some hub shutdown protection even though I have the hub protection cloud backups.
Not sure I even need to use eventghost if apcupsd is set in the config to shut down the Win server at 10%/5 minutes remaining as I have it set now.
