I have aproblem with the Shelly-Binding. I try to read when the button is pressed. I would like to get a state OFF and if I press it again the state should change to ON.
As mentioned on the shelly-binding side, I have to add the #input channel. I added the item with a switch like that:
Sounds like the channel is not linking with OH (no brainer right, ). Have a look at github and see if there is an issue similar to yours. If not you may want to open one.
I have this issue too. Items update, but sometimes it takes up to a minute - so it appears openHAB is polling each device perhaps, but push updates are not being received.
I used the Shelly app to look at the Actions settings for each of my devices, and found that the IP address configured there (169.254.13.17) was NOT the IP of my openHAB installation (192.168.x.x). Presumably the Shelly binding sets those URLs, I sure didn’t do it. Changing that IP address to my openHAB IP address fixed the issue, and the updates happen right away.
Unfortunately, when I delete and re-add the Thing (I’m using .thing files), the binding sets the Action URLs all back to that weird IP address - which isn’t even my ISP-assigned IP. I get this in my logs (I think one Shelly has a bad connection):
2020-06-29 06:15:53.650 [hingStatusInfoChangedEvent] - 'shelly:shelly1pm:68c63afb6420' changed from ONLINE to UNKNOWN
2020-06-29 06:15:53.661 [me.event.ThingUpdatedEvent] - Thing 'shelly:shelly1pm:68c63afb6420' has been updated.
2020-06-29 06:15:53.671 [hingStatusInfoChangedEvent] - 'shelly:shelly1pm:500291f01acf' changed from UNINITIALIZED to INITIALIZING
2020-06-29 06:15:53.690 [hingStatusInfoChangedEvent] - 'shelly:shelly1pm:500291f01acf' changed from INITIALIZING to UNKNOWN
2020-06-29 06:15:55.963 [me.event.ThingUpdatedEvent] - Thing 'shelly:shelly1pm:68c63afb6420' has been updated.
2020-06-29 06:15:55.976 [me.event.ThingUpdatedEvent] - Thing 'shelly:shelly1pm:500291f01acf' has been updated.
==> /var/log/openhab2/openhab.log <==
2020-06-29 06:15:57.737 [ERROR] [.eclipse.californium.core.CoapClient] - could not set and start client endpoint
java.net.SocketException: Cannot assign requested address (Error setting socket option)
at java.net.PlainDatagramSocketImpl.socketSetOption0(Native Method) ~[?:1.8.0_152]
at java.net.PlainDatagramSocketImpl.socketSetOption(PlainDatagramSocketImpl.java:74) ~[?:1.8.0_152]
at java.net.AbstractPlainDatagramSocketImpl.setOption(AbstractPlainDatagramSocketImpl.java:309) ~[?:1.8.0_152]
at java.net.MulticastSocket.setInterface(MulticastSocket.java:471) ~[?:1.8.0_152]
at org.eclipse.californium.elements.UdpMulticastConnector.start(UdpMulticastConnector.java:83) ~[?:?]
at org.eclipse.californium.core.network.CoapEndpoint.start(CoapEndpoint.java:506) ~[?:?]
at org.eclipse.californium.core.CoapClient.setEndpoint(CoapClient.java:356) ~[?:?]
at org.openhab.binding.shelly.internal.coap.ShellyCoapHandler.start(ShellyCoapHandler.java:109) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.initializeThing(ShellyBaseHandler.java:245) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.lambda$0(ShellyBaseHandler.java:129) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_152]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_152]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_152]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_152]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
==> /var/log/openhab2/events.log <==
2020-06-29 06:15:57.756 [hingStatusInfoChangedEvent] - 'shelly:shelly1pm:500291f01acf' changed from UNKNOWN to ONLINE
2020-06-29 06:15:57.764 [me.event.ThingUpdatedEvent] - Thing 'shelly:shelly1pm:500291f01acf' has been updated.
PS Thank you for the link @H102 but I don’t think it’s feasible to look through the 321 pages of results the link sends me to to resolve this problem. I can’t see any Shelly binding issues there.
Any ideas why the binding is applying this strange IP address?
Ah, I can see how to get only Shelly issues now - the link by @H102 may have been incorrectly URL encoded - hopefully this works and only has 3 pages of issues:
Looks like I should probably do an update, since I’m on 2.5.0 and now there is 2.5.6. I will try this as there seems to be a lot of active development of this pretty wonderful binding.