so that means driver doesn't support EM which is energy monitor.
Yes. It doesn't support "Shelly EM".
But it supports "Shelly Pro EM", "Shelly Pro 3EM", "Shelly Plus PM mini", "Shelly PM mini"
From here you can find Gen2 and Gen3 devices
I can't answer directly to the last question.
AFAIK drivers in Hubitat ecosystem have no graph functionality at all. This functionality is related to 'applications'. Moreover graphs in absolute most cases are implemented using external (to Hubitat) systems (based on cloud services or SBC [single board computers] based local solutions)
This driver in turn handles periodic repors that can be stored in any database associated application. Shelly devices have local storage for the last hour holding per-minute readings. Driver listens these storage reports but without further processing as it is not clear what kind of processing/interaction will benefit from this local history data while already having instant data processed before. I can imagine passing these accumulated reports in case of connection loss. But I need some specific use case to make implementation appropriate.
hmm everything you said flew over my head haha
i guess that means just stick to the shelly app for graphs and all. I think home assistant has good graphs too.
As a simple solution from "If it's working, don't touch it" perspecive yes. Tinkering Hubitat graphs has relatively high entry level.
If it's fine for you to use cloud services (Shelly cloud), then using their statistics should be a good option.
If you want badly to stay local (cloudles) and/or you want all the statistics in one place and have enough entusiasm to dive deeper into the Hubitat comunity solutios, then you can try this new challenge)
I use Maker API to do this, I subscribe devices that I'm interested in and it sends a post on each device event to a tiny service that just dumps it into timescale db, then I have grafana dashboards to graph everything.
Hello Dmitry, I have this working well with my Shelly Pro EM3 however I was wondering how often Hubitat samples data from the Shelly with your driver? I have had a few peculiar things happening with my Hub where it needs a reboot to get everything working again and was wondering if the amount of data coming in from Shelly might be the cause? I note under the Child Devices (each Phase) there is a Preference sections with Thresholds for each attrubute, is this the way to reduce the load on the hub?
Hello Roger,
It depends on device. From what I have seen it can be averaged to approximately one reading per 1..3 minutes. Driver is not sampling/polling device. So there is no such thing like polling interval. When websocket connection is established devices send reports them selves. And devices are quite noisy.
Yes. It is made to avoid attribute value changes too often. Depending on your use case you can find your balance between the amount of changes/events and reaction speed.
This way you can set bigger values for heavier loads or highly dynamic loads.
Many thanks for your quick reply Dmitry. I will try tinkering with the preferences as I don’t need to see very small changes and see how it goes.
Cheers
Roger
Good morning, I'm trying to use this driver with a shelly plus 2 PM as a roller, but it doesn't work for me and above all, I need to change the position of the roller to hubitat when it changes position.
greetings
Could you provide some more details on what exactly is not working? Logs would also be helpfull.
Another problem I have is that it does not return the value in which it is positioned to shelly for the panels and rules.
If driver is set/configured it should get position reports from the assigned device. Driver logs in debug mode have detailed traces on all the communication with device. They should provide a hint on what's going on and if something goes wrong.
Thank you very much for your interest, to ensure from the beginning, I have installed this driver and its 4 libraries
Once installed and connected, it does not report the value at which the roller is.
neither if I give the refresh option.
greetings
Did you installed also drivers for virtual/generic child devices? From your description I suspect they are missing. And so root device can't create child devices to forward readings to.
The simples way is to install the whole bundle (with all the files and child device drivers included)
https://bitbucket.org/ge4d/hubitat-code/raw/3485d0258249fa3db7a82d22ae959b7b46ac7868/Bundles/Bundle1.zip
It's a zip file that can be either imported to the hub directly or from local PC
Indeed, that was the problem, at the moment everything is already underway, I am going to work with this wonderful driver.
Thank you very much for your instructions.
Greetings
1 Like
One more issue, until now with the previous driver, the panels used the vertical dimmer adjustment.
Now this is recognized as windowshade and there is no similar control or I don't see it for panels. Is there something I'm missing or do I have to figure out how to adjust it by rules against a virtual device?
Greetings
I meant something like that
The 'cover' related child device is defined as a window shade. And dashboard sees it accordingly.
The tile should look something like
And dashboard app detects it trough coresponding capability
capability "Actuator"
capability "CurrentMeter" // add 'amperage' attribute
capability "EnergyMeter" // add 'energy' attribute
capability "PowerMeter" // add 'power' attribute
capability "Refresh"
capability "VoltageMeasurement" // add 'voltage' and 'frequency' attributes
**capability "WindowShade"** // add 'windowShade' attribute and 'on','off' commands
I need to check what is vertical dimmer.
Again it is correct. Thank you so much.
The difference is that the previous driver treated the device as a Dimmer and this one treats it as a shader, so when migrating from one to the other due to a change in the device, it requires changing the type of device and the panels on each device.
It is not something in your driver, but it makes the migration from one to the other not so fast.
Greetings and thank you very much.
Hello again, the device is a bit talkative for my taste, it reports the energy every minute despite having this configuration set, any solution?
Greetings
Yes, all shellies are chatty.
There is no way to make them send less data (except switching to polling at the cost of loosing interactivity). I did related feature request on their web page like a 6..8 months ago.
Thresholds are added to reduce event generation frequency (attribute change frequency) depending on your load and use case. Data will still come in (logs will report it in "debug" and "info" modes). But child devices will reject subtle (less than threshold) changes (can be checked trough child device logs).
2 Likes
