another issue comes to my mind: when the thing is not available at initialization time, e.g. a OH restart I could also not set the report_url to receive sensor data changed indications.
This means that all battery powered devices need to be on when OH starts 
I donāt know if itās relatedā¦or are different thingsā¦Does this happen also if you use persistence and have last values on mapdb to restore on start up?
persisting the data is not the problem
if I canāt access the device I cannot register the event url so the binding doesnāt get any updates
Iāll go to implement the following
- Discovery: As usual, things get discovered and will be added to the Inbox once it announces its service (powered on) and the binding is called. There seems to be an issue between OH mDNS implementation and Shelly so that initially the binding is not able to catch the thingās ip address (in this case the event reports 0.0.0.0 as ip address - this will be ignored) or devices donāt show up all the time. At the end thatās a minor issue and acceptable. In the worst case the user has to run a manual scan until all devices are discovered correctly.
- Thing initialization: Once OH calls the initialization handler I try to query the device settings and status. This will be used to set various device capabilities so the thing handler could act dynamically depending on the device type, mode, capabilities and the status.
- The status updater will catch up with a failed initialization so the device gets auto-initialized once itās reachable.
- When a battery powered device powers up it stays online for a while (a minute?) so there is a good chance to catch it with the next update cycle (this will be run every minute unless the devices is ONLINE).
- The update job runs every 3sec to check if a device update is required or not. The update interval can be configured in the thing settings. Default for battery powered devices is 1h for other devices is 60sec.
- This is also used to dynamically adjust polling when an event happened. E.g, issuing a control command usually leads into a changed status of some of the channel. For this I request 3 updates in a row so an immediate status update of the device get catched, afterwards the handler returns to regular update interval.
- On each update the handler checks if the device was initialized. If not it tries to (re-)initialize. The channels are updated when this was successful, otherwise re-initialization is retried on next cycle. This also covers a device, which become offline, because it was powered off (e.g. after a power outage).
This logic should cover most of the situations. In fact the thing stays in status INITIALIZING for a while, but somewhen the device gets catched and the thing gets initialized, event urls will be set and channels updated for the first time. Once event urls are set the device can stay in sleep mode until the next event gets triggered, the url is called, catched by the binding and a regular status update is processed.
I try to avoid different implementations of the thing handler to keep the flexibility. Most features are not processed based on the device type, but on the fact if a capability is available, e.g. when the device reports a meter Iāll update the meter channels etc. New device types might be implemented just by assembling the corresponding channel groups in the thing definition. There is also no need to have a 2nd implementation for battery powered devices.
Thank you very much Markus!
You donāt know how much your efforts are appreciated! 
I think none of us wants to hop around after a OH restart and press the buttons at all batter devices 
Call-to-Action
I did significant refactoring so I decided to name it alpha 5 rather than beta 1. beta 1 should be some kind of stable and will become the master branch. Therefore I need your help: Please install, verify device-by-device that the current build works and provide feedback.
alpha 5 is available here
https://github.com/markus7017/org.openhab.binding.shelly/blob/alpha5/target/org.openhab.binding.shelly-2.4.0-SNAPSHOT.jar
Devices
- Shelly 1 - fully supported
- Shelly 2 - fully supported
- Shelly 2.5 - fully supported
- Shelly HT - fully supported
- Shelly Smoke - work-in-progress, feedback open
- Shelly Bulb - work-in-progress, feedback open
- Shelly 1PM - should get discovered, but no special handling yet - contact we if you can do testing
- Shelly 4Pro - should get discovered, but no special handling yet - contact we if you can do testing
- Shelly RGBW2 - should get discovered, but no special handling yet - contact we if you can do testing
- Shelly Sense - should get discovered, but no special handling yet - contact we if you can do testing
Changes:
- new: verified support for Shelly Plug-S and Shelly HT
- new: default update interval is 60sec for standard devies and 3600sec for battery powered
- new: new channel ācolorā to service a color picker for the bulb - work in progress
- new: several thing properties like time, uptime etc. will be updated periodically
- change: thing initialization completely refactored, make it more robust against inconsistent API response data
- change: self-healing thing initialization: if the initialize fails, e.g. battery power device is not available the thing gets re-initialized on the next update cycle
- change: Channel definition for Bulb in color and white mode merged, new channel colorMode to select the bulb mode
- change: started separating the bulb specific stuff to a dedicated thing handler (too much code for the generic one)
- fix: updating battery status channels fixed
- fix: updating LED control channels for Plug-S fixed
- fix: set event reporting URL for sensors corrected
- fix: Bulb effect has to be an integer, not a string
- open: there are some problems with the thing definition, which have to be fixed for beta 1
- open: thing re-initialization is checked periodically based on the update interval. This needs to be changed to once a minute, so checking occurs even interval is 1h or so (battery devices)
- open: Bulb handling needs to be tested and verified
@MHerbst I worked on the Bulb, but need a full TRACE log if you find the time.
3 Likes
The Plug-S is missing from this list 
do you consider it fully supported?
oups, yes it is (still some issues with the LED control channels, but working in general)
Markus,
Why you didināt use RollerShutter item type to control Shelly ? It will be fine to keep it compatible with scripts.
And wan you write a little documentation about channels and textual configuration ?
Thank you.
Please keep in mind that the binding is in alpha state, so donāt expect to have a complete documentation ready by now an a lot of changes might follow until a release.
For Shelly1 with Auto OFF (1s) associated switch item never update (it stay to ON).
Ok, can i make a PR on github with a little documentation ?
Please feel free to do so, but this needs to be done against Markusā repository as it is not pushed to openhab2-addons actually.
Yes, now we could start working on details. I also want to support the color picker (item type color) etc., but as @hmerkmentioned āPlease keep in mind that the binding is in alpha stateā 
Looking forward to more suggestions.
I just started yesterday: https://github.com/markus7017/org.openhab.binding.shelly/blob/alpha5/README.md
Please send a TRACE Log as PM. So far I didnāt tried the timers. Nevertheless I would expect that the relay supports the ison property, which indicates the switch state.
Please feel free to open an issue here: https://github.com/markus7017/org.openhab.binding.shelly/issues or send me a PM.
Please make sure to include the thing type, e.g. Shelly1, Shelly 2.5 relay mode, Shelly Plug-S etc.
I just opened the issue Shelly2 relay: Thing initialization failed: Error saving the configuration!
The binding was unable to set the event URLs, instead received an error message.
I could easily clear the situation by disabling the action urls in the settings and then restarting the binding, but if other users hit that problem I could add some kind of auto recovery (see issue description)
Hello,
the binding works really well when you set it up with a Shelly 1, everything is found automatically.
Only if I put the relay output on the Paper UI and activate the switch and then reload the page, the switch is off again, but the Shelly is still active.
Can somebody help me with it?
EDIT:
I Have found it, it was only the refresh time
Thank you
fyi: Iām still working on alpha 6 to get RGBW2 in
However the current build is functional: release notes
This jar in this branch gets constantly updated until I release alpha6
Objective for beta1: A more or less consistent channel structure so that updates donāt require a complete re-install
It would be helpful if more people give it a try. @igi is doing an excellent job in testing, but feedback from others help to verfiy other environment and maybe you miss a feature, discover a bug etc.
alpha6 is done 
- bundle - jar, no other dependencies
- README - with installation & channels
- release notes
Iām still working on alpha 6 to get RGBW2 in . discovery works, channes should be there, not sure of the channel updates and commands already work.
Please do a complete re-install before you run this release (see README)
Focus for beta1:
- A more or less consistent channel structure so that updates donāt require a complete re-install
- Complete RGBW2 support
- Support for Shelly Bulb if @MHerbst could help
- Support for the Rollershutter item type
- Complete documentation on all channels
It would be helpful if more people give it a try. @igi is doing an excellent job in testing, but feedback from others help to verfiy other environment and maybe you miss a feature, discover a bug etc.
3 Likes