not very pretty to look at a rule and quickly see what it does.. the fact that it span devices on multiple hubs/devices is nice.. however, that means i assume you have to have a server that it runs on independent of whatever is running on the hubs.
Patrick Wrote this on the ezlo forum to explain more of why hes putting it together ...
Hereās how I think about it. Letās take the unmentioned firstā¦
Why make MSR when thereās Node-Red? For starters, I love Node-Red, but the fact that I love it may be something of a red flag. Itās a technical product and requires some pretty technical thinking. In a sense, itās really like the difference between Reactor and PLEG. PLEG is a great and capable tool, but not everybody gets it, and for those that do, the learning curve can be pretty daunting. Iāve always tried to keep Reactor approachable, although it has clearly grown from simpler, nascent beginning. But still, I think most people get it. So I think thereās room in the HA ecosystem for another logic/rules engine.
Second, the most consistent thing I see in the HA marketplace is that each manufacturerās rules engines are a disappointment to their users at some level. Vera, of course, never evolved a serious rules engine, probably because PLEG came early enough to take the real pressure off the engineering (or marketing) team to get it done. As promising as Hubitat seems, and as much as many people like its Rules Engine, their forums are like this one in that there are lots of posts of bugs, confusion, etc., and even the lead of that subsystem regularly admits is not everything they wish it could be. HomeAssistantā¦ well, writing automations in YAML should, in my non-serious opinion, be considered a human-rights violation. Their GUI, Automation Editor, isnāt nearly up to snuff. So again, I think thereās room for a system thatās not just cross-platform, because maybe you donāt need it to be, but it presents a friendlier and more approachable environment in which to write automations than that which is native to the platform youāre using, be that many or just one. Choices. More choices.
Third, I think cross-platform is not everyoneās concern, but can be an issue for many people because no hub natively supports everything well ā another consistent inconsistency in the HA marketplace. To that end, Iād rather have the option of using the best tool for the job, rather than accepting a compromise of 60% performance on thermostats because the platform otherwise satisfies 95% of my device compatibility needs. Thatās a horrible trade-off. If eZLO becomes as awesome at ZWave as Melih touts, then let eZLO be the go-to hub for ZWave, but that should not stop you from using Shelly or Tasmota or ESPHome or Tuya devices just because the available (or not) eZLO plugins for those APIs arenāt up to par.
Finally, itās not going to be least-common denominator. That may be the default view to keep things simple and for the majority of what users routinely use, but it is my unwavering goal to preserve access to as much as possible of the source environment. What you donāt see much of in the video is that any device from the Vera, for example, can be marked for āfull dataā. That means that device would bring over all of the Vera state variables defined on it, whether those map into a defined MSR capability or not, and you can use them in automations. That works today. I didnāt take the time to cover it in the video, it was already getting too long, but the way Iāve done Sonos plugin devices so far is a good example: there are six predefined capabilities it uses: av_transport, media_navigation, muting, volume and av_repeat. Clearly not everything you can do with Sonos, or the Sonos plugin enables you to do, is covered by these six, but they represent the majority. The rest are accessible just by tagging the device for full data, and you can do that for all devices, or devices of a certain class/criteria, or just a single device for which you have a specific need. It is also possible (today), entirely through configuration, for a user to define a new capability and add it to an existing entity (so you can make āsite-specificā capabilities), and even create custom mappings of devices to entities. For example, at the moment there is no device mapping for the DSC Alarm Panel plugin, but you could sit down and create it in your local config, without writing any code or waiting for code support from me, and make the system publish entities sourced from that device so you can see states and perform actions.
So, thatās a bunch of words that basically come down to this: more choice, more approachable.
2 Likes
I really liked Reactor on Vera and adding dedicated Triggers is a really great improvement.
My only concern is that MHR requires an external machine to run it on and this is the reason I have ignored NR on HE.
I use my C7 as my Security system (lots of battery-operated sensors and sirens etc) so I don't want another device that needs battery backup. My C7 can run for days on my dedicated battery backup system, however, all of my Server and Comms gear only stay online for 15 minutes before the UPS shuts them all down.
1 Like
Nice, what battery backup system do you use here?
Can do blockly in node-red too. Just fyi.
Probably not as seamlessly as OH3 though as you still need the input/output nodes in node-red (but that is why it is HA hub agnostic, too...).
This one:
Days? 
Definitely not on that little thing. Certainly a few hours is possible as per my testing.
I ran the numbers, the C7 load is tiny @ 0.022 Amps and I'm running genuine high quality 3500 mAh cells. I shut down after 12 hours, so yeah days is a slight exaggeration as I don't run it that long.
1 Like
Interesting. Everything I'd read prior indicated around 7 hours so this rating is a genuine surprise. I'm using one also (although with an undoubtedly lower quality Chinese cell) and have a cut-off rule at around 3 hours just to be on the safe side. Now you've prompted me to do my own testing to see how far it will go
That was because no-one tested the true power draw at the wall with a proper Power meter. The previous testing was done with a USB power meter (by @Rxich ) and so no-one really knew what the true power draw number was - 0.3 Amps turned out to be quite inaccurate (for a C7, the older hubs prolly use more power due to being built on an older Chip Fab process). Even at that load, that's still 11 hours & 40 mins runtime.
PS, here's the web calc I use.
1 Like
Cool thanks for the info. Very interesting. I've just ordered a similar but 2 battery device as a backup for an rPi. It will be interesting to see how that performs. What kind of life would you expect from such a setup? I have no idea what an rPi would draw (it's a 3b, but I'm also thinking to apply one to a series 4 RPi too if it works ok). This is the device...
THB 573.67 48%OFF | Original 18650 UPS Pro Power Supply Device Extended Two USBA Port for Raspberry Pi 4 B / 3B+ /3B, Not Include 18650 Battery
1 Like
Thanks, yeah the cheap chinese power meter is definitely not lab grade equipment, and I don't have another meter to measure mA, with kludging a bunch of connectors & wires together and putting my DMM in the circuit.
It was on a C4, so driving the hub plus the nortek stick would use more power than the C7 alone.
IIRC it was about 10 hours on a genuine panasonic 18650 3400mAh cell for my C4 and I called it off at that point.
1 Like
My high school electronics training is a bit rusty, 1.6watts @ 5 volts is about 320mA. What am I doing wrong? 0.022 A seems way to low
I just checked my C7 and got about 120mA draw at idle with 10 devices & no rules
I used a Killawatt style device so Im going on what it showed was being consumed from a 240v socket - the load is somewhat variable tho.
Kill-A-Watt (and similar) devices are typically pretty accurate, as you said.
If you measured 1.6 W on the AC mains side, and we assume the low end of the typical 80%-90% range for the AC-DC conversion (which represents the minimum power consumption from your battery), you're consuming something like 1.6 W * 0.8 = 1.28 W on the DC side.
At 5 VDC nominal, that is 1.28 W / 5 V = 0.256 A.
Your 3500 mAh battery should last 3.5 / 0.256 ~= 13.67 h. Which is indeed pretty great, but it isn't quite 159 hours as discussed elsewhere. 
I assume some digits got out of whack in all of the unit conversions.
If you go the other direction on the tolerances and empirical numbers (90% eff, 3.8 W @ 240 VAC), you get a lower end on the range of 3.5 / ((0.9 * 3.8) / 5) ~= 5.11 h.
3 Likes
AH, OK, I have a kill-a-watt also, love that device. So the 0.022 amp draw makes more sense at 240V. I tried to find documents on the hub's power drawer but was unsuccessful.
1 Like
Hereās the measurement:
Iāll get out my spare C7 and redo them without the battery UPS in the loop.
1 Like
Where are you measuring that? On the 240V side or the DC side?
I think you're in AUS. So, your line voltage is 240 V (rms). Your meter measurement if on the AC side is almost certainly in A (rms). Power = V (rms) * A (rms) = 240 * .021 = 5.04 W.
If you're measuring on the DC side, then I have no idea (which could always be true, regardless). 
3 Likes
240v at the wall socket.
Correct.
Ok, so your AC real power consumption is the meter reading multiplied by 240. 5W seems high, but maybe you're charging the battery or something.
For battery life, you need to know your DC current consumption. The worst case is that 100% of your AC power is being consumed as DC power. In practice this is more likely 80-90%.
To get DC current consumption you divide DC power by the pack voltage, presumably nominal 5 Vdc.
Then to get battery life duration you divide battery capacity (in Ah) by the DC current consumption.
You can't use the meter current capacity directly in the battery capacity calculation.
1 Like
