Sure, it is easy enough to do, and will do so in due course. The problem is also of such a nature that it may take days to manifest itself...
Just as an aside, no bearing on the current issue itself:
I am also currently forced (via a RM rule) to reboot my hub at 4AM daily now. I am regrettably one of the many suffering in silence with this issue. I was so happy at one point when I thought that I am being spared this issue, but alas, this was not to be; my issue started after I applied the second to last update. I will call my setup "mature", in that I have not added any new devices in over a year, and only tweak RM rules occasionally, so my issue is NOT a "you keep messing with it" issue. One may ask why I keep updating the firmware if all works... Simple - most folks (including HE staff) will not assist unless you are the latest firmware. I know, I tried.
Not a true statement. I am still running 2.1.3.125 on my main hub. I have update in the course of troubleshooting to see if it resolved the issue, and rolled back when it didnât, but have never been denied support due to my platform version.
Respectfully we will have to disagree on the latest version & getting support from HE. My experience was exactly the opposite of yours, where I was 2 revisions behind, started experiencing an issue & was explicitly told to bring it up to the latest revision; if my memory serves me correct I was told the error line numbers (as displayed in my log) no longer match with the latest code.
So not to be disrespectful either, truly, but then why didnât you just comply with their request and see if it solved the issue? If it didnât, you could then tell them it didnât and roll back to the version you feel comfortable with. Thatâs the whole reason they donât force automatic platform updates on you like SmartThings does, and why they built the system to allow you to roll back.
What youâre describing sounds more like they offered support and identified an issue that they believed a platform update would resolve. Not that they refused to offer you any support until you updated, which is how your earlier post reads.
I believe the latest firmware version (2.1.8) brought with it some changes to how Z-Wave devices are handled. I wonder if any of these changes could have broken this Driver? I am tagging @mike.maxwell to see if he has any ideas.
Mike - the driver in question is one of your old ones from ST, that you assisted me in porting to Hubitat back in the early days.
Here is the current code from my GitHub repository. Please advise any changes that may be required due to the Z-Wave changes in 2.1.8. Thanks!
@GatVlieg - I have made Mike's recommended change to the code in my GitHub repository. Please give it a try and let us know if it resolves the issue you've been seeing.
@ogiewon - not sure what I'm misunderstanding (usually a lot) but I've added your driver, added my Aeon HEM V1 (that I had been using w/the same driver on SmartThings for years), but I can't figure out how to use this w/WebCore in Hubitat.
I have some laundry pistons that I've imported into into WebCore on Hubitat from SmartTHings WebCore, but when I choose the Aeon HEM as the device, I don't have the option for button 1/button 1 push or held as I did in SmartThings.
There is a "pushed button" option for the Aeon HEM, but no "Held button." And I'm not clear on how I would use the Pushed Button option.
Is this driver just not compatible w/WebCore in Hubitat, and I need to use Rule Machine instead? I do see the Aeon HEM V1 as a button device, for example, in the Simple Automation Rules app, so the driver button options appear to be there, but WebCore doesn't see them...
I donât use webCoRE, so I am not sure whether or not it was properly updated to handle Hubitatâs tweaks to how Button devices work.
For now, try using one of the built-in Hubitat Apps, like Notifications or Rule Machine as a test to get things working. If things work as expected, then you could ask the folks that have been supporting webCoRE on Hubitat how to make it work there as well.
This driver only uses âpushedâ events, not âheldâ events. When the device creates a Button 1 pushed event, it means the washer is done. When it creates a Button 2 pushed event, it means the dryer is done.
Hubitat creates button events different than ST. The name of the event created by this driver is âpushedâ. The possible values are simply â1â or â2â.
Ah, thanks, my ST history was making this harder for me.
If it had been a snake...
So if I wanted a way for the piston to konw that the washer had started running, I would just use the washerWatts attribute (e.g., washerWatts >50) to identify that.
Decided to follow your lead, @ogiewon, and use a simpler RM rule w/a repeating notification until the dryer or washer door is opened. I have a 3 minute debounce to allow for power characterists as well as being able to open dryer or washer during cycle to add clothes or check dryness. Need the repeating reminder as my family tends to let things sit in washer and dryer for hours and days unless heavily pestered.
Dryer rule below. Seems to work in simple testing, running the first real load w/it to confirm the debounce settings work. Then create the washer version and call it done.
I want the total amount of wattage. Is there a line that I can add to get that as a total? I implemented Influxdb and Grafana to make Grahps. Im not really interested in individual watts but, if I can get to log all 3 (each clamp + the total) it will be great.
This particular driver really is not designed for total wattage. In fact, it explicitly configures the Aeon HEM v1 device to report individual power per CT clamp. This driver specifically is designed to be used to monitor washer and dryer cycles.
I would recommend you look for another driver that is designed specifically for power/energy monitoring using the Aeon HEM v1 device.