correct, when everything is ok I see this in the log for the switch
If not ok I see this:
After a disconnect /connect it is solved.
The problem starts on the red line. On that moment I changed the logging on the parent from Error/warnings only to info
Could you describe what do you mean by "ok" and "not ok"? Do you mean reconnection loop?
Also I did one more change to logging: While driver is now using 'logLevel' instead old input control, old 'logEnable' remains in sort of ghost mode. It is not declared anymore but still has the last value. I had to completely remove any references to it in all drivers to not to use 'compatibility' code. Now Error/warning should not spam with "info".
Regarding warning message.. It pops up at saving settings as it calls disconnect and connect to update stream in case of password change (to apply new credentials).
And disconnect call cases that warning (that "connection reset") to pop (while it shouldn't but still..).
ok= when en there is NO reconnecting in 30seconds
NOK= reconnect each 30 seconds
For some reason you need to disconnect /reconnect after a change of the Logging level on the parent, otherwise I see the connection failure
A bit of a headache with this one. But with fresh update should be working correctly now.
Here is a thing:
websocket API has no state exposed and stream state callback does not provide any data about what cause it (like function call, stream data corruption, etc; nor any 'user data' that could help when provided trough function call)
To change callback behavior depending on operation context it needs some driver state provided to it. But callback implicitely has multithreading execution policy. I.e. if calling function will set some regular driver state callback might not see it as state has sort of caching mechanism. So it is might not get properly updated. And calling 'disconnect' and 'connect' in a row triggers this case.
The driver is now using atomicState for the purpose.
Just added experimental support for DevicePower component. Shelly H&T now should report battery/mains (blindly added; no device to test at hand)
Hi Dmitry, some questions about you nice driver 
.
When I accidental hit the configure button or after changing the device profile and hit configure is needed all child devices are replaced by new ones
Should the existing childs not be overwritten/updated instead of replaced by new ones?
What is the correct procedure when there is an update of the driver, do I need to hit initialize after install of the bundel? When should I use initialize?
Has the buttons "check for updates" & "Update version Info" no overlap?
Should the password not be hidden?
For other (zigbee) devices some developers use health status, very useful if the connection between the hub and device become unavailable for reporting Apps. The Health status is online or offline. Is it an option to change Link to Health status? [Project] Device Health Status so we can use it easy in the reporting tools to?
Any plans to put the driver in HPM, easy to keep the driver up to date?
Or use a bundle for Shelly devices only?
Path_Device path, what is the meaning of this field, in what scenario should I change it?
I wonder why you don't use the System Generic Components, Button Controller, Switch, Energy Meter, Energy Meter, etc... Does it not make your life as developer more easy?
The system Generic Component Temperature Sensor is used in you driver.
Yes. During configuration all devices are recreated. This allows to cleanup "foreign" child deices if any. I was thinking on some merged version that should inteligently add/remove devices to minimize inconvinience.
"Initialize" is called by the HUB itself on system boot. It opens event stream. Same as "Connect". I cannot hide it. This way hubitat API is made. No need to use this button by hand.
"CheckForUpdates" literally asks device to do so on Shelly servers.
"UpdateVersionInfo" asks device about currently installed FW/HW/SW and updates info in the data section. With recent changes this is mostly done automatically (as driver monitors FW update process). Hovewer device can be updated in offline mode without hub knowing this. And later with this button info can be updated manually.
I need to check if input widget has attribute to mask out password.
Yep. It's easily doable. I just need to rename the "link" attribute. If this naming convention is strong accross differnt app it will be perfect.
Didn't thought about it yet.
I can add one. Though maintaining multiple bundles will add complexity for lazy me))))
From backward compatibility perspective it is quite logical to use versioned endpoint in case of protocol version progression. So at the beginning I decided to expose endpoint path in case if let's say there will be some "/rpc2" endpoint. But it is not used (for any customization) in fact.
Yes, it does. The main reason is the lack of some attributes.
Input device aside of "contact" provides "event"
Metered cover and switch add power line status (voltage, amperage, power, energy and frequency [since recent FW update])
Illuminance component device is simply missing.
Same for battery device
P.S.: Metered devices also have thresholds to mitigate event spam. Device may report changes way to frequently/aggresively. Threshold allow to skip attribute changes if they are not big enough.
would be very nice:-)
That would be very useful if you could do this;-)
@kkossev can you tell everything about:-)
After updating the driver using the bundel, do I need to do something?
No.
Bundle is a bunch of files. Updating bundle is the same as if you update all the files one by one.
Doing something after bundle update may be needed in some cases. if for example child device types changed. Then obviously you need to update child device instance set (and therefore reconfigure).
For attribute renaming there is nothing to reconfigure. Old attribute will just vanish with all the event history. And new one will appear.
Hi @dmitry.rozovik , the device is powered on/link is online, when there is a power cut for 1 min the link becomes OFFLINE, when the power comes UP , the device LINK stays OFFLINE waiting 5min+
I should think it reconnects after 30 seconds, it don't:
Is this as expected?
I it possible to add/show a driver version, easy to see If we are using the latest version....
If it were not explicitely disconnected (by issuing 'disconnect' command) it should not.
Ahhh... atomicState is not working. It is kinda there (no compilation errors) but it silently does nothing ((
Need to think how to handle it the other way around..
Update:
The driver is updated. Had to rollback to the original non-atomic state. Now connection is sligtly delayed to make 'update' function fully exit and flush 'state' changes.
P.S.: The thing is probably not in atomicState is not working but rather that websocket API control routines are asynchronous. And interface semantic policy differs from async http adding frustration. I.e. it is not clear that websocket.connect and websocket.close are asynchonous. And documentation has no mentions about that. So I have to guess if connection/disconection is complete after leaving websocket function or it is just started/scheduled.
It is actually sounds like a feature request to Hubitat team. Versioning has quite wide adoption across different custom drivers. It makes sense to promote it to the driver definition section right next to the 'name', 'namespace' and 'author' properties. Also maybe some sort of getter function and a widget semewhere in the driver UI data section.
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)
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.
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:
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.
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.
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.
Download the Hubitat app
