I am looking for a smart plug with reliable energy monitoring. Prefer ZWave, or Wifi. ZigBee unreliable in this location for some reason. Any recommendations?
Not a recomendation but rather options:
ZWave:
I have four of Aeotec Smart Switch 7 (F-plug). Cannot say anything bad. But few extra features are a bit awkward: button color can be changed and stored. but can be applied only to the current state [so you need to set it to the state that you want to apply color to first]; parameter 92 "report energy by threshold" seem to have an issue [Aeotec support team is investigating the case. Expexted to be fixed in the next fw update]
Wi-Fi:
I want to try out Shelly Plus Plug (EU). Other Shelly Plus devices make me think it should be quite interesting device.
Could you describe in a bit more details what plug you are looking for? (and what do you mean by "reliable energy monitoring"). Maybe it would help other people to give you more options.
2 Likes
If i remember right thr staff at hubitat have suggested Kasa wifi plugs for power monitoring needs. I have seen them suggested multiple times
I also have Zooz Zen04 plugs which seem to work well.
What you have to remember is power reporting can be a very chatty. On lower bandwith networks like Zwave that can create problems. You want it to report only up to what you need to accomplish your goal and no more.
To the previous posters point it would help to know what you are trying to do/monitor because not all plugs work in all scenarios.
Have found Zooz products reliable. I use three of their appliance (moderately higher amperage rating) dongles. They're very chatty but this can be adjusted via their settings.
@a.mcdear Use these, also make great repeaters. https://www.amazon.com/gp/product/B08FJ5LHSN
Yeah, so I have a couple devices in my bedroom that are controlled by IR for activation (a fan, a TV, etc) which cannot send any feedback to Hubitat about whether that device is on or not, so I wanted to be able to use the current draw from the device as a method of Hubitat being able to determine whether that device currently is On or Off.
By "reliable", I just want it to report accurately, and often enough to be useful but not too often that it causes problems.
3 Likes
Regarding Aeotect Smart Switch in the context of your goal:
For this device amperage control parameter represents a level that is when crossed by currently measured value (not the delta from the last value) triggers meter report. It can be used for the purpose if hooked device amperage level is not fluctuatin heavily (heavy fluctuation might cause ZWave spam). Minimum level to test against is 100mA with step of 100mA (equals to 23W on 230V electric network). Periodic reports are also possible but minimum rate is 600S (10 minutes). So I assume periodic reports are not an option for you with this device.
Shelly plus/pro products (I suspect it's a common behavior) send all measurements once a minute. It is significantly better than the "10 minutes" from SS7. Shelly devices don't have options to control that. I have no info on how precise amperage meter is. But I can assume it is atleast around 120mA (Can't find it in spec. So assuming accuracy of 1% from the maximum current of 12A).
Shelly devices have a local scripting capability. So it is possible to script/program the device to send you an event or a report at custom conditions (a bit sophisticated but quite flexible approach).
This is exactly my use case as well.
I have 3 different plugs from Zooz:
- Zen04( Light duty Smart plug, Newest)
- Zen15( Appliance Rated)
- Zen25(Double Plug medium duty)
You would likely want the Zen04 or Zen25(Not exactly recommending zen25 though). Basically, you need to know the load of your devices to determine on/off for what you want detect, and also minimize reporting. It needs to be a high enough number that it won't be triggered by normal use, but low enough it will trigger a report soon after the device is powered on.
With my Zen25 for instance I have it set to report every 75 watts. This works well and generally minimizes reporting since my TV generally maxes out around 140-150 Watts and fluctuates about 30-40 watts while in use.
If you set them two low you can cause allot of continuous reporting. For testing one day I set that Zen25 to report on something stupid like every 2 watts and it blew up the zwave network. I was seeing 4-8 calls a second and it quickly made the network unhealthy.
The key with Zwave power reporting is only reporting enough to catch the state you need. If you are trying to monitor actual power usage there are potentially better tools for that.
Also as I said above of those two power plugs i would recommend the Zen04. It doesn't seem to cause impact to Zwave under any normal circumstances.
If you did need the extra plugs or USB power and decided to try the Zen25 make sure you do the following
- Only include without Security
- Decide between using power threshold or Interval. And don't use both if you can help it. If you use threshold, set the power reporting interval to a very large number. like 12 hours
a. Power threshold is about change amount of change in power (this is what i mainly use)
b. Interval is about how much time between reporting. - The other reporting intervals should likely be setup much higher like 6, 12, or 24 hours unless you have a reason to get them more frequently.
After you think you have it set properly review the config values to make sure they are set the way you want them. I think part of the problem with the Zen25 device has been folks configure it and for whatever reason the settings are not what they expect them to be.
1 Like
ZEN04. Very customizable. Auto on/auto off, reporting, etc. With new firmware can set it to virtually no reporting-Kw-hr and energy duration once in a while. Recommend @jtp10181 's driver.
2 Likes
Yes this, and the defaults (on the device) are stupidly low which cause problems if not changed! I think Hubitat may have bumped up the driver defaults a little to help with that problem.
I have been getting LimitExceededException's for a few weeks now and being kinda new at this I finally went to Log->Device Stats and looked at "Count" and "% of busy". I have some real active devices like Ecobee but my ThjirdReality Smart Plug Gen2 beats it out for both count and % !! I was thinking that maybe I need to go to a different metered plug and started looking in the community posts for recommendations. It sure seems that all these type of plugs are chatty and need a little tuning... which I will do as soon as I get this post done. The only thing I use this plug for is a fan that is plugged into it that I monitor and its on/off state triggers an automation. So, I don't need anything fancy and If someone has a recommendation as to the least chatty plug I sure would appreciate it.
Thanks
Would be helpful to see the exact errors you are getting. I am not familiar with what a "LimitExceededException" looks like, so am missing some context.
Did you update the firmware on the TR plugs? They have put out a few fixes which reduces the amount of messages it sends.
For configuration, good luck, TR devices usually ignore any configuration and just keep doing whatever they want.
The error looks like the following:
I no longer have the logging for this error for the ThirdReality anymore... I booted up with the option to redue the DB and clear the logs... sorry. But I believe when this error is caused it effects lots of automations. From a fresh reboot it takes 12 hours or so to start with this error and it shows up on sendEvent() and sendLocationEvent(), etc.
I will be "tuning" my TR plug but just in case I don't succeed do you have a recommendation on a plug that will probably give me better results.
Thanks A Lot
I thought I would show the following Log of the situation:
The last entry corresponds to the original TR plug that I was using and swapped it out for the first entry which is a 2nd TR plug that I purchased. Both, when active, have about the same performance characteristics. This represents pre-tuning and I will put up a post-tuning a little later. The stats above reflect about an hour of running after reboot.
Ya i got rid of my third reality as the parameters for power reporting did nothing and when notified refused to fix it. It may be better now but i doubt it.
That error is for an app, you need to click on where it says "error" in red to open up the app and see what it is. The error is not being thrown by the plug driver or the plug itself.
Your Stats screenshot also shows no pending events for the TR plug device, which I do not think it queues up events at all so I would not expect to see anything there.
I ran two of the TR plugs for about 2 months with holiday lights and had no issues. Yes they were the most chatty devices I had but Zigbee can usually tolerate it. Updating the firmware to the newest greatly reduces the number of messages they send.
The only other ones I have are Sengled which seem to work good, allow you to configure them and do not spam out messages constantly. They are however more expensive. You get what you pay for.
I wish I had the report to all those exceptions... this is the only one I had by virtue of copying it from a prior post. This particular one points to (In the App) a sendLocationEvent(). I have had others that are not App: related but Dev: related. When I go to the line in the Dev: it shows sendEvent(). The source of the Exception is always one or the other. I believe once this condition is caused it will never clear up and I have had to reboot.
You may want to sort both the devices and app stats by Total events, Hub Actions and Pending Events. Something is jamming up the event queue from the looks of it. Possibly the Ecobee stuff, looks like that is a lot of events for only an 3 hours.
You should be able to find it. its app 819
And remember that the Exception I showed above is an example among many I had back then. Just recently (And I do not have the stats because I rebooted with wiping the logs!) it seemed to point at the Tr plug. The post from jtp10181 might have a point and I am weighting that concern. I have made some adjustments to the TR device driver and will share that soon. It looks like it has potential.
Thanks
