Driver is updated:
Added 'em1' component experimental support (Shelly Pro EM and Shelly Pro EM3 in monophase profile mode; some 'mini' devices also fit here)
Fixed 'cover' component mapping for 'stopped'/'partially open' state.
1 Like
Thanks for updating this state mapping, I appreciate it!
I've looked further into the HomeKit issue and I don't see it relating to the driver implementation. With a virtual driver synthesising position and windowShade (state) attributes, I experience the same issue. I'll post elsewhere to try and investigate further.
I read few post in this forum.. And I can try to help within the scope of the driver.
At least one post mentions dependency on position value. So could you track this attribute in different states and post results here? Meybe there will be a chance to see some dependency.
Can someone please let me know if there's a driver that works with Shelly Plus 1 with Shelly Plus Add-On? I'm looking for a driver that will report temperature from the the Add-on!
1 Like
I can add 'Shelly Add-on support'. But I need a bit of help with testing)
From driver perspective the only difference is child device id range that is not continuous.
P.S.: I have an idea how to add add-on related childs in generic way. Going to update the driver soon for testing.
1 Like
Driver is updated:
-
Changed component enumeration logic from total count to ID lists. Different addon modules now expected to be properly visible to the driver.
-
Changed internal naming for temperature sensors that are related to switches and/or dimmers. Those will be recreated after 'Configure' operation. This is needed to avoid id conflict between Shelly Plus 1/2 build-in sensors and add-on sensors.
-
For add-on module 'temperature' and 'input' components are expected to be supported.
| peripheral type | component type | support |
|---|---|---|
| ds18b20 | temperature | yes |
| dht22 | temperature, humidity | yes |
| digital_in | input | yes |
| analog_in | input | yes |
| voltmeter | voltmeter | needs new child device |
Needs testing.
2 Likes
Thank you very much Dmitry, I'm happy to assist with testing but I live in Australia and the Shelly Plus 1 modules are out of stock everywhere here atm. Been told they expect stock at the start of April. I'll 100% test as soon as I can get my hands on one.
1 Like
Good news, I seem to have resolved the issue with HomeKit. The driver casts the position to a Float for the event value. By removing the cast and refreshing the devices, everything started reporting the proper status in HomeKit. It appears to expect an integral number.
events << [name: "position", value: params.current_pos as Float, unit: "%"]
^^^^^^^^
What tipped me off was the built-in Mirror app was configured at one point to mirror the cover child device to a built-in Virtual Window Shade device. The Mirror app was reporting a NumberFormatException in the logs.
java.lang.NumberFormatException: For input string: "95.0" on line 416 (method sourceHandler)
1 Like
Driver it updated with your fix)
Thanks!
1 Like
My driver targets Gen2+ devices (Mini/Plus/Pro). Shelly EM is Gen1 device.
And this driver is not present in HPM.
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?
