I have an outdoor Shed that houses my homes water well pressure tank equipment and also serves as a shelter for our outdoor pets. I have a small heater in this shed to keep it at a comfortable temperature for the pets and to ensure that the pipes don't freeze when it gets cold. I'd like to monitor the power / energy usage of this heater. First to make sure it's working when I expect it to and also to track how much electricity it's consuming. I purchased some Z-wave controlled outlets that report amperage, voltage, watts and kWh for this purpose.
Due to the distance the shed is from the house I was having trouble getting the Z-wave signals out that far. I tried adding as many repeaters as close to the shed as possible but there were some devices I could get to pair but others I could not. Since I actually have Cat5e running out to this shed I decided to just get a 2nd HE hub and do a linked hub.
Now that I have the 2nd hub and have it linked I'm finding that none of the "virtual linked devices" seem to support power / energy monitoring. Is this a known limitation? Any suggestions on workarounds? My biggest reason for wanting to use linked devices is I want to have both a dashboard that displays the current status of the devices as well as notifications via Pushover for when the heater turns on / off. Since I can't have Pushover on both hubs at the same time and I don't think you can link Dashboards across hubs I'm not sure how to achieve what I'm wanting to do here.
Could I log a feature request for adding power / energy sensing outlets to the list of "linked" devices?
In the meantime: Are there any suggested workarounds?
I wish the hub-to-hub linking worked 100% differently.
The need for new sets of 'device drivers' for the linked device really hampers use of non-traditional or multi-function devices.
Just thinking out loud... But I wish there were a 'container' type device. On this device, have a configurable/selectable list of capabilities, and then a configurable set of variables to pull from the remote device and map into the selected capabilities.
Or a way for it to just use the full physical device driver (as it already describes the capabilities and attributes easily enough), but in 'virtual mode' and then have the hub link just pass the variables over.
I don't know...
I do know, though, that the hub-to-hub linking is restrictive enough I can't use it for many things I want to without writing new virtual drivers (like I believe @srwhite did). And I just don't have the energy for that right now.
But I don't see any of this changing any time soon.
Sure you can! Just add another virtual Pushover device on your second hub and use the exact same keys from the first hub. Pushover doesn't care. I have it running on multiple hubs.
The challenge with Hub Link/Link to Hub are all of the combinations of attributes/commands that exist. If, for example using the OP's example, one wants to link an Iris Smart Plug to a remote hub. The virtual device driver needs to support both the switch and power attributes. But Z-Wave switches, which use that same driver do not report power, yet would expose that capability to apps. A smart smoke detector, like a Halo has 7 attributes that report, versus a ZCOMBO that has 2 or 3 depending on whether it supports CO. There's potential safety issue if someone were to build an automation for CO detection using a virtual device which supports the capability but is linked to a physical device that does not.
There exists some issues with using a driver that supports 7 attributes on a device that only reports on 3. First, since those capabilities are exposed in the driver, all apps will think that device supports those when it in fact does not. In my opinion that results in a poor user experience, since it becomes possible to create automations based on unsupported capabilities.
Those are the reasons why I coded my own solution. I'm not sure if I'm going to release it because it's huge; 4 apps and 23 drivers currently. There's no way tech support could provide any assistance should anything go wrong.
Yeah I agree with @srwhite here... A monolithic container doesn't seem like a great option.
Rather: It seems like they just need something that will auto-generate a custom "stub" driver that has the same commands / attributes as the remote device, and simply passes commands to the remote device driver and reports back any of the attributes. IE: Auto-generate a proxy device for any device on the remote linked hub.
Anyway: Back to my immediate problem... @ogiewon solved my Pushover problem (Or rather pointed out that it wasn't ever a problem) the only remaining issue for me right now is the dashboard: Is it possible to get dashboard data from a linked hub to show on a master hubs dashboard?
The answer to that again comes down to what attributes the remote device reports to the virtual device on the master hub. Virtual, linked devices can be used in the dashboard on the master hub. You just may not get all of the same data displayed that you would if the device were locally connected.
I meant more along the lines of: Build the dashboard on the remote hub and then just link the dashboard itself. Then you don't have to worry about the device reporting data, it's then just up to the dashboard to report the data.
What happens if you create a Small Dashboard on the Shed Hub. Then use that URL as a link tile inside the main Hub's Dashboard. You would effectively be switching between the two dashboards, but it would be a little more seamless than having to exit out of one to open the other. Note: I haven't tried it...just thinking out loud...
And that's the reason I think the hub linking in its current form isn't very useful/sustainable. I think the entire architecture needs to be re-thought.
I still think the virtual device should use/import the physical device's driver, and populate the values to pass based on that. If the value is on the physical device - whether it is real, or an extra variable - it is hard to argue that passing it to the virtual device is any more risky than it existing on the master device to bgin with...
I also was thinking that it would be "slower" if (when you're inside the home) and the Internet is down, frustration would build having to re-link the dashboard nav buttons.
It would be slow.. as in never.. but while you're looking at it, thinking "why isn't it coming up?" seconds pass before the "oh man, these are Cloud links" occurs.
It's OK... long ago figured out that we post messages to each other, BUT also to the 'lurkers' that might not read this for a month. If it wasn't clear to you today, it certainly won't be 'easier' for others in a month. Please, feel free to make me be clear.
I have a question. If the shed hub is connected to the ethernet cable and it is also connected to his router then couldn't he access the shed hub through it's IP address? The shed hub would then have a dashboard built around the devices he has on the shed hub. This would give him the child devices of the outlets because they are included on the shed hub. He could also access the shed hub from outside through a VPN.
The only draw back would be that he could not control a rule on his main hub from the results on the shed hub but could control a rule on the shed hub which would still give him a pushover. At that point he can log into the shed hub and see what is wrong.
Fundamentally I think there's no "Best Way." The power data isn't passed over Link to Hub so a Dashboard on a different Hub can't provide that insight. A Dashboard on the Shed Hub can reveal the data, but getting to it is cumbersome.
Neither way is good. Lots of 'hacks' are available, sure... including the SRWight way (srwRIGHT way?)
Iām working on something similar passing data via the maker api to virtual devices.
(Seems the easiest way to pass the data)
But you are right, to be able to cover all attributes and commands will be a mammoth task.
