Polling HT and Smoke will definitely fail, as they go to deep sleep after a certain time. There is no keep alive option, cause this would drain the batteries.
It seems like CoAP and MQTT actions are mutually exclusive on the shelly configuration (at least on the shelly 2.5 that Iâm trying) so I cannot keep both enabledâŠhow do you keep both running?
As soon as I check MQTT the CoAP action gets unchecked on the device.
If it is soâŠthis will slow down my test as I have to choose one device to pull out from my production systemâŠand change sitemaps rules etcâŠ
Another thingâŠI cannot see the binding neither in the PAPER UI â Configuration â Bindings or in the Binding list in the autodiscovery page modal windowâŠis it normal? Openhab apparentely started without any error after the installation.
Thanks
donât change the config of the Shelly. The plan was/is to use CoAP and it works in parallel to mqtt - there is a visualization issue in the UI.
For the moment the binding doesnât make use of Coap.
I do, are you sure that you copied the jar into the addons folder. Open the OH console and run bundles:list, get the ID and try âbundle:start â. The bundle has to become active. If not enable TRACE log and send me a PM.
after powering up my Shelly1 I have to report that itâs not running. I fixed a bug related to device discovery, but processing the relay status to update the channels doesnât work yet. I keep you posted
ok, here is alpha3
https://github.com/markus7017/org.openhab.binding.shelly/blob/alpha3/target/org.openhab.binding.shelly-2.4.0-SNAPSHOT.jar
- fix for the âNot foundâ in Paper UI when adding the Shelly2-roller (duplicate channel)
- support for Shelly1 - itâs not âa half Shelly2â, itâs specific
- avoid exception on thing discovery
again you need to remove and re-add all things and clean out the JSON DB
Shelly 1, 2, 2.5 look good for me
feedback on other devices welcome
@alexxio informed me that had to to install feature esh.tp-coap in addition
feature:install esh.tp-coapAutodiscover for Plug S and HT sensor not working yet (I manually turned on the HT sensor and ran the autodiscover).
2019-07-16 22:14:48.479 [ERROR] [discovery.ShellyDiscoveryParticipant] - Device discovery failed for device shellyplug-s-7af169, IP 192.168.10.33: null
2019-07-16 22:33:06.336 [ERROR] [discovery.ShellyDiscoveryParticipant] - Device discovery failed for device shellyht-58f736, IP 192.168.10.35: null
Tomorrow I will try to add them manually.
Iâm just trying to catch the exception with @igi, he has the same problem with the Plug S. I checked in a build, which does a line-by-line debug so I could see, which line leads into the exception.
Please use the jar I checked in some minutes ago. This also corrects the thing type for the 1PM.
I applied a fix for the devices, which donât have a mode: HT, Smoke, Plug, PlugS
@igi reported successful discovery for the Plug S
@MHerbst Could you please re-test the Bulb with alpha3
https://github.com/markus7017/org.openhab.binding.shelly/blob/alpha3/target/org.openhab.binding.shelly-2.4.0-SNAPSHOT.jar
I added a new Thing config option to alpha 4, which allows to set the update interval. The default is 15sec (has to be a multiple of 3). That is an interims solution for the HT and Smoke, so they get only polled every x seconds, e.g. 14400=every 4 hours to avoid battery drainage. I need to work on the fix for the event callback, which provides a general interval, but event driven updates.
did you gave the binding a try? more feedback welcomeđ€Ș
With alpha 3 my bulb gets discovered.
I did not have the time to add and configure all the things yet.
Here are my test results:
- Bulb: white bulb and my Plug S are now detected automatically
- Bulb: changing the brightness of the bulb in Paper UI has no effect
- Bulb: effect can not be changed. it shows only â-â in Paper UI
- Bulb: Color Bulb can be added manually. Changing the values e.g. for the colors has no effect
- Plug S: display of watts and power shows nAn (BTW: after adding an item for the bulb brightness it showed also âNaNâ but the widget in Paper UI could be changed to a different value. There seems to be a general problem with numeric values.
I can send you trace outputs if you need them.
I am not sure whether it is good and intuitive to use two different things for the Bulb, but I donât have a better idea yet either.
yes , please send the trace log by PM
Please find alpha4 in the repo:
https://github.com/markus7017/org.openhab.binding.shelly/blob/alpha4/target/org.openhab.binding.shelly-2.4.0-SNAPSHOT.jar
@igi helped me a lot with testing , so we could make significant progress - thanks Igi!!!
- fix: thing type id for shelly2-plug-s fixed, so now you get the full set of Meter channels
- fix: Meter channels for Plug S get filled, thing definition corrected
- fix: Avoid exception on invalid number format ($power)
- fix: Avoid exception on event callback
- new: seperate thing types for Shelly2 and Shelly2.5 - the 2.1 has 1 meter, the 2.5 has 2
- new: added a 2nd Meter to the Shelly 2.5 relay channels so both meters are accessible
- new: meter data is accumulated when in roller mode (mapping 2 to 1 meter)
- new: timestamp channel added to meters
- new: output firmware version to the log (and thing properties)
- new: check for FW > 1.5 (thatâs the minimum version, I donât want to provide backward compatibility to older releases)
- change: Thing gets online after the status was successfully updated for the first time, not at initialization time
- change: COAP usage disabled until I understand how to initialize for observing non-standard options
Shelly2/2.5 things:
Given the diffrent set of meaningful channels and the difference in the number of meters (Shelly2: 1, Shelly2.5: 2) this results in 4 different thing types:
shelly2-relay: 2 relay, 1 meter
shelly2-roller: 1 roller, 1 meter
shelly25-relay: 2 relay, 2 meter
shelly25-roller: 1 roller, 1 meter (kumuliert aus beiden Meter, timestamp = newest measurement)
Known issues:
- Shelly Plug S: Status updates on LED control channel
- Shelly RGBW2 is not yet finally implemented
- Progress on the Shelly Bulb is made, but still work in progress
- The polling frequencyneeds to be optimized by utilizing the event callback when sensor data has changed
- The event trigger channel is not yet implemented - this will trigger a notification to an OH rule each time an event is received
- http authentication is currently not implemented, this means you have to disable http auth for the build-in web server
- The binding starts one update thread per device, this needs to be consolidated making the device handling more efficient
Some channels might be missing, some need some fixes. If you see something post on the forum or send me a PM inlc. TRACE log for bugs.
Feedback is highly appreciated.Does someone hast a Shelly Smoke to test?
4 Likes
ok, I did more testing and found several issues with the HT. I had to add various if() to validate API results data. There are various fields, which donât get filled, e.g. numMeters with the Shelly 1 even it has a meter. Some if those inconsistencies resulted in exceptions on discovery and thing initialization. Thatâs also the reason why devices might donât show up on the discovery.
Channels for Shelly Plug-S and HT have bern fixed, all data gets updated.
Let me do some more testing with
Shelly 1, Shelly 2-relay, Shelly 2.5-roller
Plug-S, Shelly HT
Iâll provide beta 1 soon (maybe later today or tomorrow).
Does anyone know if the HT/Smoke could be waken up with Wake-on-LAN, otherwise thing initialization will fail when in sleep mode
1 Like
Only know for HT, no remote wake up possible.
hmm, not the best
maybe I could raise a feature request at Shelly, butâŠ
I already added an if(Sensor) to prevent to go OFFLINE when the poll fails, but that doesnât solve the situation while initializing the thing.
As I wrote earlier, no polling for battery operated devices.
They stay in deep sleep mode for battery saving until a sensor treshold is reached. Best would be to put those devices into a separated handler, so we can think of the best way to support them independent from the other devices.
A feature request at shelly does not make sense.
as I sayed this doesnât solves the initialization while the device is in sleep mode
I already implemented the report_url event callback - so the binding gets updates by events.
Yes, but we can split the battery driven devices from the mains driven an the implementation for those can be finished independent.
I believe thereâs not much we can do about the autodiscovery of the battery driven devices.
With the HT you can manually trigger the sensor on with the internal button and it should stay on for a couple of minutes and then manually run the autodiscovery in that time frame.
1 Like