First: use firmware 1.9.3+
and then I need a DEBUG log to see initialization
Thanks! Let me see what i can do. The device is also refusing to connect via MQTT (tried that instead of via Shelly binding. Will take this up with Shelly support to see if the device has an issue. Will come back once i know!
I now see this every 15 seconds in my log:
2021-03-01 11:40:00.321 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyLightHandler tried updating the thing status although the handler was already disposed.
Doesn’t reference any specific thing/device.
Is it anything to worry about?
restart the binding/OH
I had a strange effect when I updated today from 3.1M1 to 3.1M2.
My Shellies did not report LONG_PRESS and SHORT_PRESS anymore.
I installed the latest dev build with the same effect.
The debug log showed only the button events ON and OFF.
I did not change anything in the shelly setup. They are still in detached switch mode as before.
When I change the to momentary, I get the button press events again.
But I cannot use momentary as I have to detach the relay output from the input as I link them by rules.
Nothing changed in the binding, do you have the build you used before to do a cross-check?
fyi: PR #10220 has been merged. This brings the next OH3 milestone build to the current feature level, except the Shelly Manager. This will be the next PR I create shortly.
2.5 users: There will be NO update to the 2.5 code stream, you have to stay or to move to the DEV build if you need features and fixes after the 2.5.10 version. This doesn’t relates only to the Shelly binding, but to all others as well. 2.5 will only receive critical fixes anymore.
Before falling back to 3.0M1, I would like to know if the button press events should be handled in detached mode or not.
there are no button events in detached mode, how should that work?
1 Like
Markus, just like to understand: why is the state of a roller shutter (0=open, 100=closed) inverted to shelly’s original state which can be read on device’s web server (0=closed, 100=open)?
Because Shelly uses 0…100 where ipenhab uses 100…0, but you have the „original“ value in the rollerPos channel
1 Like
Hello,
I want to use my Shelly Plug / Plug-S in OH3. At my last installation (2.5) they work fine.
With this OH 3.01 installation no device is found with the scan.
If I create the thing manually, the status is unknown. The log shows:
==> /var/log/openhab/events.log <==
2021-03-05 07:19:19.720 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shellyplugs:Waschmaschine_rechts’ changed from UNINITIALIZED to INITIALIZING
2021-03-05 07:19:21.723 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘shelly:shellyplugs:Waschmaschine_rechts’ changed from INITIALIZING to UNKNOWN
Shelly Firmware 1.9.4
Where is the problem?
Best regards
Thomas
make sure you are on the DEV build, if problem persists I need a DEBUG log
Latest DEV builds: 2.5.13 - 3.1.0 - README - Installation - Avdanced Users - Shelly Manager - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The DEV build is always newer than the version in the official Distro or the Milestone builds (SNAPSHOTs); OH Distro 2.5 will not receive updates anymore, so you have to switch to DEV build when running OH 2.5, see installation notes.
I do not understand your comment.
According to my knowledge, a shelly supports button events in momentary and detached mode (“Click events are only send when the switch is configured as momentary or `detached swich”).
Detached mode is absolutely useful if you want to control the relay by rule only.
I used several shellies in detached mode with button events up to 3.1M1.
Does the binding filter events depending on the button type?
If you need it, I could search and install the binding which was part of M1 again for testing.
I use a Shelly1 for a door bell (switch) and door opener (output).
Obviously the switch has to be in detached mode otherwise it would open the door as soon as anybody rings the bell😂
Which OH version do you run? Standard build or test build?
my comment was aimed at supporting your use case and to make other users understand that it does make sense to have a detached physical switch.
I am running latest test build but I do not make a difference if button is pressed long or short
yes, the bindings filters the button type, those events are available in momentary, momentary_on_release, 1-button and 2-button mode. If an on/off switch is connected to the relay there is no push event. In this case you could trigger on the input channel. Of course detached has it’s benefit. this means
- the switch is attached to Shelly 1 - could trigger button or input event
- Shelly 2 is in detached mode and receives the command to switch the output on/off
- and a rule in between
this is exactly how I configured my Shelly device. This way it is a very easy to install replacement for a door bell with door opener.
@Vogelrain Just for completeness: You can also differentiate if the detached button is long pressed or short pressed:
when
shelly:shelly1:doorbell:relay#input triggered SHORT_PRESSED
shelly:shellyix3:doorbell:status1#button triggered SHORT_PRESSED //(in case of a Shelly X3)
or
when
shelly:shelly1:doorbell:relay#input triggered LONG_PRESSED
shelly:shellyix3:doorbell:status1#button triggered LONG_PRESSED //(in case of a Shelly X3)
make sure you are using the DEV build
Latest DEV builds: 2.5.13 - 3.1.0 - README - Installation - Avdanced Users - Shelly Manager - Bugs/Features - Firmware Index - Firmware Archive - API Doc
Note: The DEV build is always newer than the version in the official Distro or the Milestone builds (SNAPSHOTs); OH Distro 2.5 will not receive updates anymore, so you have to switch to DEV build when running OH 2.5, see installation notes.
ok. why?
Works perfectly with all versions since OH2