Yes, the DTH exposes a “reset” custom command that can be used to reset it, but doubt any of the built-in apps support custom commands so you’ll most likely need to use a community SmartApp like CoRE or WebCoRE to execute that command.
I think this device should use ocfdevicetype: oid.d.smartplug to change the logo to a plug in the new app instead of a switch. I did it for mine and it works great
hi @krlaframboise does the change to power active change the output of power in webcore
also, can I find the version 1.6 device handler?
you can log the energy/KWH at the same time every day/week. Don’t reset the meter. Then if you forget to look for a day/week, you still have the total consumption, and you could prorate it. Pros don’t reset meters - you would lose information.
Kevin’s DTH can be set to report energy once per day or once per week. ST’s own log is limited, still 7 days worth? or maybe less now.
No. The handler users the acceleration sensor capability to report active when the device’s power exceeds the threshold and inactive when it drops below it.
I implemented that features because I was trying to keep track of the frequency my sump pump was running, but it generates a lot of power reports while running. Using the active/inactive status solved that problem.
You could pull it from the GitHub repository history, but the DTH should be backwards compatible so why do you need it?
Probably, but until they stop making changes that break things in the new mobile app and publish the damn documentation I’m not wasting any more time screwing with the new mobile app…
That reminds me, DO NOT USE THE SETTINGS SCREEN IN THE NEW MOBILE APP!!!
They made a change this week and the enum settings are no longer handled the same way so if you attempt to change a setting in the new mobile app it will send the wrong value to the device and the only way to change it back to the setting you wanted is to use the classic mobile app…
That most likely broke at least 30 of my DTHs so I’m keeping my fingers crossed that they’re going to put it back the way it was…
Hi @krlaframboise
how are you doing your sump pump monitor are you using webcore if so can you show your code?
what do you have the value set to for power inactivity
i was think about the 1.6 device code as u am running 1.2 firmware on both of my devices
I wrote a SmartApp called Simple Event Logger and use it to log those active/inactive events. It’s posted on the forum…
I found that it didn’t always report 0 immediately when it turned off so I used 25.
The one my sump pump is connected to has 1.1 firmware on it…
All the handlers I write support all firmware versions so there’s never a reason to stay on an old version.
The only exception to that is when the changes affect the capabilities, like adding lux reporting to the Zooz Outdoor Motion Sensor, but for that device I created a new “VER 2.0” topic and handlerr so that both versions are still available on the forum.
Hi @krlaframboise is Acceleration Sensor or Actuator for active/ inactive ?
also, I noticed in the keypad to enter the number the dot looks like a -
Acceleration has the active/inactive events. Actuator is a generic capability that indicates that the device has commands that can be executed.
I think ST implemented number fields so that if you enter “.” as the first character it changes it to “-” so try putting a zero in front of it. If that doesn’t work try entering 2 “.” to see if it changes it to “-” the 1st time and then back to “.” the 2nd time.
@krlaframboise todo 25 do i need 25 or 25.0
It should just be 25, but if it automatically adds the .0 after you save it won’t hurt anything.
My response is based on the assumption that you’re using my Simple Event Logger SmartApp to log these events in Google Sheets.
You could create a pivot table that has the logged data on one sheet and the filtered data for each on separate sheets, but pivot tables can be really slow if you have a lot of data in the sheet. I usually try to avoid messing around with pivot tables in the active workbook (sheet file) because I’ve seen the logging process get messed up, but it’s rare and usually only happens if you have a lot of data in the sheet so it might be fine.
The easiest solution is to install an instance of the SmartApp for each switch which will allow you to log each device’s events in a different workbook.
Any additional questions about this should be posted to the SImple Event Logger topic.
If you’re using that other logging SmartApp then a pivot table might work fine, but you should post the question on that topic.
I am trying to use WebCore to turn off a Zooz Zen 15 Ver 2.0 smart plug (using version 2.2 of krlaframboise device handler) if my shallow well pump stays running for more than an hour to prevent the pump from burning up. I could not find an app that will look for power exceeded for a period of time before turning off the plug (Smart Lighting will just turn off the plug after a period of time being on and does not take into account if there is load on the plug or not) so I decided to take the plunge and give WebCore a try.
I am new to WebCore but found a piston that was close enough to what I needed and got it set up. The code works perfect when testing using a Fan and a simple Neo Zwave switch using just the built in SmartThings Power Metering Switch Device Handler.
The problem I am having is the code just loops with the Zooz Zen15 which I need to use to handle the higher power requirements of the shallow well pump. The code runs fine and will alert if the switch is turned on, will alert if the switch is turned off and will alert if the switch “stay greater” than X power for X minutes however with the Zooz device the code just loops at notifying and never makes it to the turn off part of the code. Looking at the trace in WebCore the stay greater part of the code will turn green as it should when the power exceeds the value for the defined time but then after a few seconds go back to red causing the loop. I have tweaked every reporting interval in the device handler for the Zooz device and even tried using just the power metering device handler with the Zooz plug with the same results.
Any suggestions would be greatly appreciated because I am really stumped and would be very bummed if my well pump ran all night and got fried because I can’t figure this out.
Attached is a picture of my piston. I have all the times turned down to seconds just for testing.
EDIT: Didn’t realize you also wanted to turn the device off, my apologies.
Did you Disable On/Off Control in the DTH’s preferences by chance? What does Live logging show for that device when trying to turn off?
I did not disable the On/Off Control in the DTH (that is probably the only item I did not change). I was assuming that option should not be changed.
Below are screen shots of all the settings I have in place. I am guessing for some reason the Zooz plug or the device handler reports a power value of 0 at some point which causes webcore to think the power is not “staying greater than” the defined threshold for the defined time and that is why I can see the if statement turn green which generates the first SMS notification and then I see the if statement turns red and then goes back to green which then loops right back to the first SMS notification.
Just as a reminder with a simple Zwave plug the code works perfect so that is why I know I am just missing something with the Zooz plug.
Ok, I thought I’d ask just in case. Tagging @krlaframboise on this one.
Which SMS message does it keep sending?
It loops after sending “Well Pump has Been on for an Hour” with the Zooz switch. So I get the “Well Pump has Been on for an Hour” over and over. I did watch the live logging of the Zooz switch and it is reporting the power correctly so my theory of a bad power report is not correct.
I suspect the power repeatedly being reported above 10 watts during that 2 minute grace period is causing the problem and I added that active/inactive feature for a similar use case.
If you change your piston to “acceleration stays active for 20 seconds” and set the “Report Inactive when power…” to 10 then that will most likely solve your problem.
Having the device send 4+ reports every 5 seconds is completely flooding your mesh so I’m surprised you’re not having global performance/reliability issues.
For all your metering devices you should disable the reports that you’re not doing anything with and make the others only report as often as you need them to.
Energy is cumulative so I can’t think of any use cases that would require it to be reported every 5 seconds.