you also need to install californium. On marcus website you find the modules. Shelly binding normally installs this as dependency but here you have to do it manually.
Sorry, I use shelly bulb duo, not bulb…
And today my Shelly Manager stopped working again.
So it would be very interesting to know why.
Maybe one reason is I deleted cache and made a restart of openhab yesterday.
Hello!
I’ve managed to manually install 3.4.0-SNAPSHOT, but I had the same problems as I had with binding installed via PaperUI. On Marcus’ github I found 3.1.0-SNAPSHOT of the binding and after installing it, it started working again as it was before OpenHAB update. One other thing I’ve noticed is warning in openhab.log that constantly shows up (with 3.4, as well as with 3.1):
Handler ShellyLightHandler tried updating the thing status although the handler was already disposed.
It shows 4 warnings every half a minute or so.
Hopefully, someone will find out what’s going on with official (PaperUI) binding, so I can go back to that version again.
Thank you for your help.
Best regards,
Davor
Hello everybody,
shelly has published an new device: Shelly Plus Plug S
It is the successor of the Plug S switch with new functions (messuring and rgb-LED-ring)
I think, there are new channels, which are not supported by the actual binding.
However, as far as I know, the Shelly binding determines the available channels dynamically. Does that mean that such a new device is then automatically recognized or does the binding for the new device have to be extended?
I find the device itself interesting because the colored signaling can also be used for status displays (alarm system or “windows/doors open”) and the plug is considerably cheaper than the one from Fibaro, for example.
Thanks, Ralph
Hello,
Since a long time, I have problems with my Shelly Buttons, but now the problem gets massive and renders them all nearly unusable. Hope that someone here can help me:
With Openhab 3.0 everything was fine and the buttons worked great. After installing OH 3.1, the problem started: After a restart of OH, button presses weren’t recognized - to be precise, the first two weren’t recognized and the third and all following ones worked normal.
Since some time (guessing OH 3.4, maybe earlier), after a restart of OH, all buttons won’t work for a long time, no matter how often I press them etc… As an example: I tested around yesterday evening, and this morning most of the buttons need to be pressed three times until recognized by OH.
What I found out is, that the buttons seem to normally send their network packages: I sniffed with Wireshark on the machine that runs OH and found that for all button presses I could reliably receive CoAp network packages. I also saw that after a OH restart, the first button press (sometimes?) caused OH to call the /settings endpoint of the Shelly. But after that, any further button press didn’t result in any OH reaction. It takes a long time and/or lots of button presses to make OH react to button events…
I also tested if I mis-configured something in OH and started a clean installation of OH on my machine. I added just the button thing manually with its IP using UI but no button presses got recognized and the thing stayed in status UNKNOWN.
I repeated the steps on a second PC with the same result.
This is the output from my clean installation:
21:49:32.447 [INFO ] [re.automation.internal.RuleEngineImpl] - Rule engine started.
21:49:58.982 [DEBUG] [.shelly.internal.ShellyHandlerFactory] - Shelly Button 1: Create new thing of type shelly:shellybutton1 using ShellyRelayHandler
21:49:59.025 [DEBUG] [.shelly.internal.ShellyHandlerFactory] - Thing handler for uid shelly:shellybutton1:3a7eb8ed7f added, total things = 1
21:49:59.040 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellybutton1:3a7eb8ed7f' changed from UNINITIALIZED to INITIALIZING
21:50:01.046 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Thing name derived from UID shelly:shellybutton1:3a7eb8ed7f
21:50:01.048 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Using userId admin from bindingConfig
21:50:01.049 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Device config: IP address=192.168.101.194, HTTP user/password=admin/***, update interval=900
21:50:01.051 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Configured Events: Button: false, Switch (on/off): true, Push: true, Roller: true, Sensor: false, CoIoT: true, Enable AutoCoIoT: true
21:50:01.053 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Start initializing for thing Shelly Button 1, type shellybutton1, IP address 192.168.101.194, Gen2: false, CoIoT: true
21:50:01.054 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellybutton1:3a7eb8ed7f' changed from INITIALIZING to UNKNOWN (CONFIGURATION_PENDING): Initializing or device in sleep mode.
--Button pressed--
21:50:16.070 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Unable to initialize: API Timeout for GET http://192.168.101.194/shelly, retrying later
21:50:16.074 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Update status job started, interval=300*3=900sec.
--Button pressed 2x--
--Shelly Button connnected to USB--
--Setting status interval query time to 60s in UI--
21:52:16.874 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Stopping Thing
21:52:16.875 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Shutting down
21:52:16.877 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Shelly statusJob stopped
21:52:16.881 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Thing config updated, re-initialize
21:52:18.882 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Thing name derived from UID shelly:shellybutton1:3a7eb8ed7f
21:52:18.884 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Using userId admin from bindingConfig
21:52:18.886 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Device config: IP address=192.168.101.194, HTTP user/password=admin/***, update interval=60
21:52:18.889 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Configured Events: Button: false, Switch (on/off): true, Push: true, Roller: true, Sensor: false, CoIoT: true, Enable AutoCoIoT: true
21:52:18.891 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Start initializing for thing Shelly Button 1, type shellybutton1, IP address 192.168.101.194, Gen2: false, CoIoT: true
21:52:18.896 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Starting CoAP Listener
21:52:18.898 [DEBUG] [helly.internal.api1.Shelly1CoapServer] - Initializing CoIoT listener (local IP=10.244.235.192:5683)
21:52:26.053 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Using CoAP device description from successful HTTP /cit/d
21:52:26.054 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: CoIoT Device Description for shellybutton1-3a7eb8ed7f: {"blk":[{"I":1,"D":"sensor_0"},{"I":2,"D":"device"}],"sen":[{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":2},{"I":2102,"T":"EV","D":"inputEvent","R":["S/L/SS/SSS",""],"L":1},{"I":2103,"T":"EVC","D":"inputEventCnt","R":"U16","L":1},{"I":3115,"T":"S","D":"sensorError","R":"0/1","L":1},{"I":3112,"T":"S","D":"charger","R":["0/1","-1"],"L":2},{"I":3111,"T":"B","D":"battery","R":["0/100","-1"],"L":2},{"I":9102,"T":"EV","D":"wakeupEvent","R":["battery/button/periodic/poweron/sensor/ext_power","unknown"],"L":2}]}
21:52:26.056 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id=1: sensor_0
21:52:26.057 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id=2: device
21:52:26.060 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Adding 7 sensor definitions
21:52:26.061 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 9103: cfgChanged, Type=EVC, Range=U16, Links=2
21:52:26.062 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 2102: inputEvent, Type=EV, Range=S/L/SS/SSS;, Links=1
21:52:26.062 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 2103: inputEventCnt, Type=EVC, Range=U16, Links=1
21:52:26.063 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3115: sensorError, Type=S, Range=0/1, Links=1
21:52:26.064 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3112: charger, Type=S, Range=0/1;-1, Links=2
21:52:26.065 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3111: battery, Type=B, Range=0/100;-1, Links=2
21:52:26.066 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 9102: wakeupEvent, Type=EV, Range=battery/button/periodic/poweron/sensor/ext_power;unknown, Links=2
21:52:26.194 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Auto-CoIoT is enabled, disabling action urls
21:52:26.195 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Starting CoIoT (autoCoIoT=true/true)
21:52:26.196 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Stopping CoAP Listener
21:52:26.197 [DEBUG] [helly.internal.api1.Shelly1CoapServer] - CoAP Listener stopped
21:52:26.198 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Starting CoAP Listener
21:52:26.199 [DEBUG] [helly.internal.api1.Shelly1CoapServer] - Initializing CoIoT listener (local IP=10.244.235.192:5683)
21:52:26.225 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Using CoAP device description from successful HTTP /cit/d
21:52:26.226 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: CoIoT Device Description for shellybutton1-3a7eb8ed7f: {"blk":[{"I":1,"D":"sensor_0"},{"I":2,"D":"device"}],"sen":[{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":2},{"I":2102,"T":"EV","D":"inputEvent","R":["S/L/SS/SSS",""],"L":1},{"I":2103,"T":"EVC","D":"inputEventCnt","R":"U16","L":1},{"I":3115,"T":"S","D":"sensorError","R":"0/1","L":1},{"I":3112,"T":"S","D":"charger","R":["0/1","-1"],"L":2},{"I":3111,"T":"B","D":"battery","R":["0/100","-1"],"L":2},{"I":9102,"T":"EV","D":"wakeupEvent","R":["battery/button/periodic/poweron/sensor/ext_power","unknown"],"L":2}]}
21:52:26.228 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id=1: sensor_0
21:52:26.230 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id=2: device
21:52:26.231 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: Adding 7 sensor definitions
21:52:26.232 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 9103: cfgChanged, Type=EVC, Range=U16, Links=2
21:52:26.234 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 2102: inputEvent, Type=EV, Range=S/L/SS/SSS;, Links=1
21:52:26.235 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 2103: inputEventCnt, Type=EVC, Range=U16, Links=1
21:52:26.236 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3115: sensorError, Type=S, Range=0/1, Links=1
21:52:26.236 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3112: charger, Type=S, Range=0/1;-1, Links=2
21:52:26.237 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 3111: battery, Type=B, Range=0/100;-1, Links=2
21:52:26.237 [DEBUG] [elly.internal.api1.Shelly1CoapHandler] - shellybutton1-3a7eb8ed7f: id 9102: wakeupEvent, Type=EV, Range=battery/button/periodic/poweron/sensor/ext_power;unknown, Links=2
21:52:26.238 [DEBUG] [g.shelly.internal.api1.Shelly1HttpApi] - shellybutton1-3a7eb8ed7f: Set Sensor Reporting URL
21:52:26.241 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Updating channel definitions, 4 channels
21:52:26.242 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#deviceName
21:52:26.243 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#updateAvailable
21:52:26.245 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#heartBeat
21:52:26.246 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#statusLed
21:52:26.251 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Channel definitions updated
21:52:26.257 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Initializing device shellybutton1-3c6105f44d2d, type SHBTN-2, Hardware: Rev: prod-2020-10, batch 1; Firmware: v1.12.1-ga9117d3 / 20221027-094830
21:52:26.258 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Shelly settings info for shellybutton1-3c6105f44d2d: {"device":{"type":"SHBTN-2","mac":"3C6105F44D2D","hostname":"shellybutton1-3C6105F44D2D","sleep_mode":true},"wifi_ap":{"enabled":false,"ssid":"shellybutton1-3C6105F44D2D","key":""},"wifi_sta":{"enabled":true,"ssid":"Link","ipv4_method":"static","ip":"192.168.101.194","gw":"192.168.101.22","mask":"255.255.255.0","dns":"192.168.101.22"},"wifi_sta1":{"enabled":false,"ssid":null,"ipv4_method":"dhcp","ip":null,"gw":null,"mask":null,"dns":null},"mqtt": {"enable":false,"server":"192.168.33.3:1883","user":"","id":"shellybutton1-3C6105F44D2D","reconnect_timeout_max":60.000000,"reconnect_timeout_min":2.000000,"clean_session":true,"keep_alive":60,"max_qos":0,"retain":false,"update_period":30},"coiot": {"enabled":true,"update_period":15,"peer":""},"sntp":{"server":"time.google.com","enabled":false},"login":{"enabled":false,"unprotected":false,"username":"admin"},"pin_code":"","name":"multimedia-button.wohnzimmer.i","fw":"20221027-094830/v1.12.1-ga9117d3","discoverable":true,"build_info":{"build_id":"20221027-094830/v1.12.1-ga9117d3","build_timestamp":"2022-10-27T09:48:30Z","build_version":"1.0"},"cloud":{"enabled":false,"connected":false},"timezone":null,"lat":500.000000,"lng":500.000000,"tzautodetect":true,"tz_utc_offset":0,"tz_dst":false,"tz_dst_auto":true,"time":"","unixtime":0,"led_status_disable":false,"debug_enable":false,"allow_cross_origin":false,"actions":{"active":false,"names":["shortpush_url","longpush_url","double_shortpush_url","triple_shortpush_url"]},"hwinfo":{"hw_revision":"prod-2020-10","batch_id":1},"sleep_mode":{"period":12,"unit":"h"},"led_status_disable":false,"longpush_duration_ms":{"max":800},"multipush_time_between_pushes_ms":{"max":500},"remain_awake":0,"inputs":[{"name":null}]}
21:52:26.259 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Device hasRelays:false (numRelays=0),isRoller:false (numRoller=0),isDimmer:false,numMeter=0,isEMeter:false), ext. Switch Add-On: n/a,isSensor:true,isDS:false,hasBattery:true (low battery threshold=20%),isSense:false,isMotion:false,isLight:false,isBulb:false,isDuo:false,isRGBW2:false,inColor:false,alwaysOn:false, updatePeriod:43260sec
21:52:26.260 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Thing successfully initialized.
21:52:26.268 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Update status job started, interval=20*3=60sec.
21:52:26.270 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellybutton1:3a7eb8ed7f' changed from UNKNOWN (CONFIGURATION_PENDING): Initializing or device in sleep mode. to ONLINE
21:52:28.359 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Updating channel definitions, 4 channels
21:52:28.362 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel status#input
21:52:28.364 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel status#button
21:52:28.366 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel status#lastEvent
21:52:28.368 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel status#eventCount
21:52:28.377 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Channel definitions updated
21:52:28.409 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Updating channel definitions, 6 channels
21:52:28.410 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#charger
21:52:28.412 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel battery#batteryLevel
21:52:28.414 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel battery#lowBattery
21:52:28.415 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel sensors#lastError
21:52:28.416 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel device#wakeupReason
21:52:28.417 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Adding channel status#lastUpdate
21:52:28.422 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Channel definitions updated
21:52:28.424 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellybutton1-3a7eb8ed7f: Event filtered: EXT_POWER
I don’t know if it was coincidence, but I saw the following message in the log on my production machine after the first button press that was recognized by OH:
coap Exchange[L2241] with manual token overrides existing Exchange[L2111] with open request: KeyToken
I am running OH inside a Docker container with --net host with openhab/openhab:latest, currently v3.4.1 . All Shelly Buttons run latest firmware v1.12.1-ga9117d3 and have a static IP configured. All devices are in same subnet. The problem is present for buttons that I own for about 2 years and for buttons that I recently bought and integrated into OH.
I would be thankful for any hint what I could do to track this down.
Thanks, Andreas
Edit: Note that the problem is limited to Shelly Buttons; other battery-powered Shelly devices like e.g. DW2 work as expected.
Hey Andreas,
I might be in the same boat as you, but havent had time for extensive testing.
I have a shelly1 connected to my doorbell so that the shelly sends the Button press and oh knows the doorbell rang. Since a few weeks this doesnt work any longer.
Since i also moved to a docker setup with own dedicated IP, im not sure if it was an Update or the move to Docker.
I set the Shelly to unicast by IP and Port. The only thing i noticed when entering the docker Container, that i was not able to list the listening Port where OH is set to receive the COAPs.
“Netstat -tulpn pipe grep Port” should have found a Java process and Listening Port on the interface IP at least, i guess.
But yeah, i havent had time to troubleshoot in more detail.
Best
@davorf Usually you could ignore this message or turn on DEBUG log and provide an extract to locate the state. Make sure to use the matching version. If you are on 3.4.2 use the version coming with the Dist.
@RalphSester As mentioned I’ll look into that shortly. I already have a Plus Plug S and a Smoke available.
@atetzner @waitz_sebastian I think you are right. The binding shouldn’t call /shelly and /settings for battery powered devices once they were initially added. The device could already returned to sleep mode and is no longer accessible.
Did I forgot to respond to an open issue?
1 Like
crap, not all my answers were saved
If Shelly Manager reports an NPE it might be related to a specific value/state returned by the device handled improperly. You should turn on DEBUG logging and check openhab.log
Yes, you’ll find DEV builds for 3.4.2 and 4.0 in my myfiles repo under shelly. If you are on 3.4.1 use the version coming with the Dist.
@Spaceman_Spiff @Oliver2 @bastler The binding creates most channels dynamically on thing initialization. However, if device access fails or maybe some unsupported values are returned this process is aborted. I wondering why channels are removed from an existing thing, because the binding never delete existing channels, but adding missing ones (e.g. new version of the binding supports additional channels). Sometimes the are left-overs in the OH cache, esp. when updating the DEV build in the adding folder, try openhab-cli clean-cache.
@davorf You are right. A long time ago I separated color and white mode into 2 things having a clean channel layout. However, I see you point. I need to think about, what could be a good solution.
I have a Plus Plug S and Smoke on my desk and will add them soon (not this week).
Ok, more answers missing?
2 Likes
I did a simple restart of openHAB and have not modified anything. I’m running on stable.
Almost all my devices are missing the channels (except maybe ca. 2-4).
Even with missing channels they properly show
- the status
ONLINE - Up to date thing information
The log shows no warnings/error.
When I tough the *.thing files with the configuration everything gets loaded and works as expected.
During the last two restarts this behavior occurred two times so it’s pretty much reproducible.
I’ve set all devices in CoIoT peer mode.
@markus7017
Would it be possible to at least add the basic channels of the appropriate thing? E.g. If I have configured a shelly:shelly25-roller then it’s safe to assume that there should be a channel
- roller#control
- roller#state
- roller#input1
- roller#input2
- meter#currentWatts
- meter#totalKWH
The device supported these since the start of sales.
Example configuration which should always have these channels:
Thing shelly:shelly25-roller:889F5E "Shelly25: Rollladen" @ "Raum1" [deviceIp="XXX.XXX.XXX.XX"]
Maybe an easy solution would be to specify a firmwareNewerThan configuration option?
Then I could add it to the thing file and it would allow proper initialisation without device configuration?
E.g.
Example configuration which should always have these channels:
Thing shelly:shelly25-roller:889F5E "Shelly25: Rollladen" @ "Raum1" [deviceIp="XXX.XXX.XXX.XX", firmwareNewerThan="1.11.7"]
I never saw, never heard about an issue like that. Did you tried an older firmware?
We should investigate the root cause and not build work arounds.
As I said, the binding doesn’t delete channels. Turn on TRACE, the channel creation is shown in openhab.log
The is no acknowledgment by the device and the binding doesn’t repeat commands on errors. Even in this case it doesn’t make sense, because the device entinto sleep mode and is no longer available. There is no way to wakeup a Shelly.
You could create a watchdog. When a command is processed correctly the device sends an status update. You could create a rule, which
- sends the temp change to the device
- and checks after 5sec that the new target temp is the desired temp
Most of my devices are on 1.11.7 from end of 2021, some are on 1.12.1 So not the latest but not really “old”. Both versions were equally affected
I agree, however having a sensible set of default channels (e.g. for a shelly25-roller a shutter channel) definitely makes sense.
The thing only gets created when the *.thing file gets loaded, so of course the binding can’t delete channels.
Maybe the problem is because I’ve set the device into CoIoT peer mode it doesn’t answer some kind of broadcast (or it takes too long) and when the thing is created from the file the required information it not yet available. However I’m just guessing.
@markus7017 : Thanks for your reply. I’m sorry if this is a dumb question, but how does postponing calls to /shelly and /settings (hopefully) solve my issue, that the Shelly Buttons events aren’t recognized for a long time after an OH restart?
@markus7017 & @atetzner
For me its not a battery powered device. Its a regular good old Shelly1 and I have the feeling its network or process related on in the docker container.
My Shelly1 is configured to ColoT with IP:Port like this:
.23 is the IP of my OH3 server. its the dedicated IP of the OH3 container within the docker VLAN.
So now checking the service on OH server port 5683 from within the container. One has to apt install net-tools before:
root@openhab:/openhab# netstat -tulpn| grep 56
udp 0 0 0.0.0.0:5683 0.0.0.0:* -
root@openhab:/openhab# netstat -tulpn| grep 8443
tcp 0 0 0.0.0.0:8443 0.0.0.0:* LISTEN -
While Openhab port is listening, the ColoT port isnt.
Also I cannot telnet tcp:5683 from the same local LAN, but can OH3 web port.
So in the end, I think the ColoT messages cannot be delivered to Openhab since the TCP endpoint is not available from shelly1 device point of view.
Any ideas welcome
As you can see from the netstat output, the CoIoT port is a UDP port. That said, I think this is the intended behaviour/output of netstat:
UDP is connectionless. Unlike with TCP, it has no concept of “listening”, “established”, “closed”, or anything like that. If a UDP port is open, it appears in the listing; if it’s not open, it doesn’t. There is no other state to display. Showing
LISTENINGor something similar in that column could imply that there are other possible states, and that would be false.
Source: windows - Why UDP does not show LISTENING in the state column in netstat? - Super User
I think this is also the intended behaviour as telnet only works with TCP, as far as I know. Connecting to an UDP port and pretending it is a TCP port won’t work, as OH will not answer with the required packages to perform the TCP handshake. You could use nc to connect to the UDP port and send some bytes to it.
Edit: Sorry for just saying “everything you observed is the normal behaviour” - this obviously doesn’t help you with your problem. Maybe you could try to sniff the raw network data using Wireshark to find out, if the packages get delivered to the OH CoIoT port. If you find out, that the packages get delivered, maybe it’s the same problem as I have …?
1 Like
UDP is a connectionless protocol, this ist the reason why you don’t see LISTEN state.
BTW: use “ss” command instead of netstat from net-tools. netstat is deprecated.
“ss” shows for UDP UCONN or ESTAB.
See my (working CoIoT) setup output:
# ss -unlp | grep 5683
UNCONN 0 0 *:5683 *:* users:(("java",pid=1508,fd=234))
You can also trace the network traffic with tcpdump on OH host if there are incoming Coap packets:
tcpdump host <Shelly Device IP> and port 5683 -n -vv -X
1 Like
Thanks for your explanations @igi and @atetzner .
tcpdump confirms receipt of UDP packages from the Shelly1 appx. every 15 seconds. When ringing the bell connected to my Shelly1 I even see more UDP packets flowing. So its not network or service.
Thanks for your help on this.
1 Like
Hello!
I can’t use matching binding (the one installed through Paper UI) because in that case I can’t switch between color and white modes.
I haven’t mention my use case earlier, so it might explain why I need it. When Plex is playing movie/TV show, mode is switched to color and color of the bulb matches dominant color of the Plex poster. When Plex is paused or stopped it switches to white light and predefined intensity.
Anyway, thank you for your reply.
Best regards,
Davor