Why should they put effort in it? They never show the driver versions + It is already possible:
If is a good practice to keep such things under centralized control. And it doesn't need much effort. I can't imagine it might take more than 8 man/hours for a person who is closely fammilar with firmware internals.
It's not like they never show version. Built-in drivers have strong relation to Hubitat firmware version. And with that in mind for them internal driver version initially looked redundant (I suspect)
"Standarts are great. Everyone needs one" )))))
Yes, Though, once again it is at a level of some developer group that do decide it will be their way and format. Not like it's bad. But having that at platform level is definitely better. (just my personal humble opinion)
2 Likes
Correct, they are the best to use, if they to exist :-), not easy to get new ones on the HE roadmap 
Other question, on input child there are the events: single, double, long and even triple_push.
How can I get them in the app Button Controllers?
I need to check the app. I don't khow what it does and how it works.
But RM should be able to use it. By checking "custom attribute" for a specific value.
1 Like
From what I can see I can extend Input child device to become compatible with the app (no reconfiguration will be needed).
There are two ways to do it:
- Is to map all events to button attributes accordingly. Tripple tap will not be available to the "Button Controllers" app this way.
- It is possible to map each event to a separate button number. So tripple tap for example could be 3rd or 4th button.
One moment that is not clear to me yet is if app will react to the attribute getting the same value in a row like repeated action. By default attributes skip events in such cases - need to experiment a bit locally to see how it will behave.
1 Like
Added experimental support for "Button Controllers" applications family.
Remapping matrix for each input event child device
Note: For proper button count devices need to be reconfigured (number of buttons is set at child device creation). Not critical to ignore: the only consequence is a long list of inexistent buttons to choose in the "Buttons Controllers" application.
"Hold" behavior needs testing.
2 Likes
What a clever solution to add triple push in button controllers, of course it does not meet the standard of the app, "Standarts are great" LOL. My feeling, there is a little bit to much delay for double click compared to triple click.
Unfotunately I can't check delay. I have no direct access to the device atm. From code perspective it simply forwards device event. Nothing fancy inside.
Theoretically it can be tested using Shelly script (as a secondary option) so the result could be compared agains each other. And to check for sure if it is device specific (if delay is nearly the same) or someting happens along the processing logic.
The double_push events comes directly from the device. It is not virtually generated.
1 Like
Hello, I am looking at purchasing a Shelly EM3 Pro and wondering if your driver is now stable and can you advise the link to download it?
Thanks
Well.. I expect it is stable enough)
Regarding features related to Shelly Pro EM3:
Mostly operational.
Device it self is quite chatty. So child devices have thresholds to adjust according to your use case
The feature still lacking is a emdata component readback. It is related to the accumulated consumed energy. AFAIK device once per hour sends a report with accumulated readings.
To add related support I need real life logs. This feature is related to readings gathered while device were offline.
All instant reading should be good (voltage, amperage, power, energy)
Sure. Links to related posts (link and installation info):
1 Like
Thanks for your reply and work on developing the driver. Will give it a go!
Cheers
1 Like
Driver is updated with:
- Password is now masked out
- Fixed incorrect version stage for 'beta' update reports (showing them as 'stable'; update command itself is not affected)
- Removed never changing 'devicePath' parameter
Virtual battery powered device:
- Added 'powerSource' to more nicely describe charging process when available ('battery' or 'dc')
- Added 'batteryState' attribute instead of 'alarmBattery' ("idle" or "discharging")
2 Likes
Nice to see some improvements, keep up doing the good work:-), thanks
Any progress or plans on those topics:
-
Renaming the link attribute to health status
-
I don't think it is easy for new users to find your repo
Integrate it in HPM? Make a new topic? -
Add the driver version, something similar as this:
The better re-configuration is ready to some extent. Right now I have a version where only device addition takes place. I.e. "Configure" will have an option ("update" or "clean"). Yet it still lacks specific deivce removal (like in case of profile change to remove only "shade" (or only "switch") devices). [Not published yet]
And I have some initial draft on a "Shelly BLU gateway" app to manage bluetooth devices. Curently the idea is to register all of the gateway-capable devices (that should participate in bluetooth management) inside an app. Then an app will spawn virtual child devices for detected bluetooth sensors. I want to try to use an app as some sort of root to support kinda "migration" (meaning some BLE devices may be moved and report trough a different gateway device due to this)
Waiting for sample BLE device to "play" with.
1 Like
New driver update:
Configure ("update") now can remove unused child devices (except 'EM' component; WIP).
Added 'thermostat' component support for the Shelly Wall Display.
Support is incomplete as there is no documentation regarding related component nor code samples. All the new functionality is based on assumptions and device behavior observations. Setpoint is controllable, driver properly decodes unit settings changes. But on/off function is not currently working.
2 Likes
This the final solution! THX
@dmitry.rozovik any change you will add the health status so we can use it in the Device Activity Check and Device Watchdog apps?
I'm thinking on how to do that in a versatile way. Hubitat platform recently added a way to monitor custom health status as a custom row in the device list table. And I like this idea of making it configurable. To either somehow hook to this functionality (and forward to the health status attribute) or duplicate somehow.
It makes sense on a platform level as each and every device may have different attribute (and different meaning) to watch for a "healthy" device. It may be link status, it may be relay temperature or input voltage level, etc. It can be anything depending on context.
So I consider direct forward of the "link" attribute the health status attribute rather like a fallback if there will be no better (more flexible) solution.
(In a mean time driver is updated with healthStatus attribute)
================================================
A side of it I got H&T device (unfortunately device to test BLE gateway functionality is still on the way). It works a bit differently from what I imagined based on a documentation: basically it can't maintain websocket open as it is constantly in a sleep mode except periodic wakeups to update screen and send data to either cloud service and/or to trigger hooks.
To handle this without opening hub ports nor using Maker API I'm adding so called virtual child devices to the driver. Firts two will be temperature and humidity devices. The amount of them will be configured trough a parent device. The will get data from Shelly scripts using special event naming (script will be able to fire an event to the specific virtual child device if such type is supported or to the "variable" attribute otherwise to keep ability to workaround/forward using hub functionality).
Here is how it is going to work: Shelly H&T hooks will be set to trigger endpoints on some other plus/pro device (that is by nature permanently listening). This plus/pro device will have a shelly script that simply forwards hook to the driver trough its permanently open event stream to a specific virtual child device. And this way hub/driver will get instant temperature/humidity reading without cloud service and without exposing external access to the hub
Unfortunately it adds some complexity. But on the good side is the ability to make kinda isolated subnetwork of two (or more) devices that locally do some temperature/humidity automation that is immune to loosing hub connection for any reason.
2 Likes
Nice, thx for that, check this @kkossev 
Should it no be forwarded after X time offline?
Was there a change on the configure button with this new release?
If I read your plan with the H&T device, Is the goal to merge this in the existing driver or is it a separate driver?
It looks possible to implement.
Yes. As optimized child device addition/removal is working no point to keep two options. Driver will keep only relevant child devices.
Merge to an existing. A functionality to spawn virtual child is added already, Yet the arey not used atm. Currently script events are decoded as:
- Shelly.emitEvent("number", value); --> script::customNumericAttribute
- Shelly.emitEvent("string", value); ----> script::customTextAttribute
- Shelly.emitEvent("text", value); ------> script::customTextAttribute
- Shelly.emitEvent("variable", value); --> script::variable
Temperature and humidity most likely will be forwarded as something like:
- Shelly.emitEvent("humidity:<X>", value); -----> virtualHumidityX::humidity
- Shelly.emitEvent("temperature:<X>", value); --> virtualTemperatureX::temperature
1 Like
