Thank you for finding that issue. I'll verify it then update the code.
2 Likes
Until V008 all device messages were processed by updateDeviceStatus. This change restores that processing.
Here is my take on fixing this error. It's been a while since I worked on this code and I value your thoughts, suggestions and opinions. This works for me, kindly let me know if it works for you, or post what works for you. I'll update Github when we all agree on the updated code.
Note: After initial post I updated code correcting an error when status Commlost was received that did not contain the UPS' data elements. June 20, 2022 13:19EDT
// Response to a getUPSstatus call
else if (json?.data?.device)
{
if (enableDebug) log.info "Device update received."
if (json?.data?.device.timeleft)
updateDeviceStatus(json.data.device)
if (json.data.device.status != 'ONLINE')
{
log.warn "SmartUPS ${json.data.device.upsname} driver is ${json.data.device.status}"
if (json.data.device.status != 'ONBATT')
sendEvent(name: "lastEvent", value: json.data.device.status)
}
}
I expect it is ok for me, I left off the if condition you have for device.timeleft, running updateDeviceStatus regardless of the message, but I don't fully know the possible messages that could be received... Happy to give your version a go.
Thanks for taking a look at this.
COMMLOST messages do not have the UPS' device.timeleft and other information, causing an error when attempting to process with updateDeviceStatus(). Test this condition by disconnecting the UPS -> USB connector from the windows machine.
1 Like
Happy to accept your experience in this case.... So if you know of a situation where this condition is required, then I'm happy to see it included.
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.
