Shelly Binding

Ablablab · May 16, 2021, 8:40pm

I’m trying shelly binding on Shelly i3 on M3.1 (after upgrading from Stable 3.0). I’ve added my 2 I3 using the scan and all seems to be ok:

2021-05-16 22:22:52.262 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyix3:a4cf12f4780b' changed from ONLINE to UNKNOWN
2021-05-16 22:22:55.512 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyix3:a4cf12f4780b' changed from UNKNOWN to ONLINE
2021-05-16 22:22:57.360 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyix3:a4cf12f4780b' changed from ONLINE to UNKNOWN (CONFIGURATION_PENDING): Initializing or device in sleep mode.
2021-05-16 22:22:57.501 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyix3:a4cf12f4780b' changed from UNKNOWN (CONFIGURATION_PENDING): Initializing or device in sleep mode. to ONLINE

The problem is that the only trigger I can receive is RESTARTED.
Conf is Button events ON, Push Events ON, COIOT events ON, General Update Interval 60. I tried several reboot, unlink of the model and unpair of the thing.

I tried to change from mcast to unicast COIOT (with port autocomplete). All my shellies are running with COIOT.

I tried the debug:

59878084 cloud_aes.c:573         free mem: 38708 / 31768, bytes to send: 720
59880904 cloud_common.c:1533     Stop status keep alive timer
59964104 cloud_common.c:1120     Cmd: status
59966663 cloud_common.c:136      Confirmed status serial 11
59969679 cloud_common.c:1123     Cloud stop status timeout
59973574 cloud_aes.c:573         free mem: 39252 / 31768, bytes to send: 32
60179089 shelly_switch.c:161     switches: 00000007
60181720 ix3.c:314               ==== physical inputs changed: 0x06 -> 0x07 is_initial=0
60375419 ix3.c:533               temperature 82.350753
60685570 shelly_multipush.c:297  ==== registered multipush sequence "shortpush" (cnt=2) on input 0 (switch 1)
60893010 json.c:420              RAM: 50936 total, 38880 free
60898214 cloud_aes.c:573         free mem: 38784 / 31768, bytes to send: 720
60901048 cloud_common.c:1533     Stop status keep alive timer
60963681 cloud_common.c:1120     Cmd: status
60966242 cloud_common.c:136      Confirmed status serial 12
60969260 cloud_common.c:1123     Cloud stop status timeout
60973130 cloud_aes.c:573         free mem: 39344 / 31768, bytes to send: 32
63609857 mgos_http_server.c:180  0x3fff1f34 HTTP connection from 10.21.22.139:59499
63619462 json.c:420              RAM: 50936 total, 38076 free
65375410 ix3.c:533               temperature 82.109845
66697592 shelly_ping_check.c:154 Ping 10.21.22.24 (1)
66703967 shelly_ping_check.c:109 Ping response (1, 5)
68580532 mgos_http_server.c:180  0x3fff1f34 HTTP connection from 10.21.22.139:59500

where 10.21.22.21 is my openhab host, and 139 is my pc with opened web gui.
From events.log and openhab.log I can’t see any trigger (except of RESTARED).
I’ve tried to link the channel button and last status to some new points to use a watchdog rule on it without success. What can i do to use these devices?
What am I missing?

Oliver2 · May 16, 2021, 11:29pm

please post your rule so that we can start helping

jeroenvdd · May 19, 2021, 1:18pm

Hi,
just a simple question i have several smartbulbs in you binding,
is there an easy way to make an on/off (for the dimable bulbs)
now I’m doing it by setting the brightness but that gets me into issues when making a habpanel that just toggles

DrRSatzteil · May 19, 2021, 7:21pm

You can’t just use a toggle to send ON or OFF commands to the brightness channels. That’s the way most bindings work.

hmerk · May 19, 2021, 8:00pm

Who says that?
Per definition and that‘s how most bindings work, a brightness channel accepts ON/OFF commands as well as PERCENTAGE values, also the according dimmer item. This is also included in our docs.
Here is a code snippet from my Wemo Dimmer implementation

            switch (channelUID.getId()) {
                case CHANNEL_BRIGHTNESS:
                    String binaryState = this.stateMap.get("BinaryState");
                    if (command instanceof OnOffType) {
                        value = command.equals(OnOffType.OFF) ? "0" : "1";
                        setBinaryState(action, argument, value);
                        if (command.equals(OnOffType.OFF)) {
                            State brightnessState = new PercentType("0");
                            updateState(CHANNEL_BRIGHTNESS, brightnessState);
                            updateState(CHANNEL_TIMERSTART, OnOffType.OFF);
                        } else {
                            State brightnessState = new PercentType(currentBrightness);
                            updateState(CHANNEL_BRIGHTNESS, brightnessState);
                        }

DrRSatzteil · May 19, 2021, 8:09pm

Sorry… Stupid autocorrection…

You CAN, you CAN…

Should stop replying from my phone

hmerk · May 19, 2021, 8:22pm

Better disable autocorrection

jeroenvdd · May 19, 2021, 8:25pm

Strange thing is ON seems to work OFF doenst…
But in my happanel when I send on it turns on but the button doenst change color because it detect a brightness level not the command it has sent

DrRSatzteil · May 19, 2021, 8:29pm

It can be incredibly useful though. I guess it’s my fault to blindly rely on it sometimes

jeroenvdd · May 21, 2021, 4:05pm

tested again with the OFF and ON in habpanel and latest DEV,
the GU10 doesn’t go out with ‘OFF’ command

Mark_VG · May 22, 2021, 5:53pm

Hi All

I hope I did this right?

github.com/openhab/openhab-addons

[shelly] Shelly EM - add powerFactor channel support

opened 05:52PM - 22 May 21 UTC

Mark-VG

enhancement

* Version used: openHAB 3.1.0.M4 * Environment name and version: Java Runtime A…zul Systems, Inc. 11.0.9.1 (Zulu11.43+55-CA) * Operating System and version: Windows 10/10.0 (amd64 The Shelly EM3 supports the powerFactor channel as per the docs. It appears however that the ShellyEM does not support the powerFactor channel, even though this appears to be available on the device: ![Shelly EM PF](https://user-images.githubusercontent.com/84638697/119236259-b2f59880-bb36-11eb-8933-7a49eb220553.png) Firmware on Device: 20210429-102232/v1.10.4-g3f94cd7 The PF is used to calculate an accurate VA value from the reported Watts value so is important. Would it be possible to implement this as a feature?

Thanks for the support
Mark

Mario_Aerni · May 25, 2021, 9:29am

Hi,
I migrated (basically set up a new OH3) my OH 2.5 instance to OH 3.
Everything went smoothly, except some problems concerning the shelly motion sensor.

I’m currently using openHAB 3.0.2, with the Shelly Binding 3.1.0.202105081702 and I encounter the problem, that no motion item is updated.

In the shelly manager, it’s visible that CoIOT messages are received from the motion sensor.

The IP set in the WebUI is also correct.

The thing setting (file based) is:

Thing shelly:shellymotion:60a423937252                      "Shelly Motion - EG Cloakroom"                  [deviceIp="192.168.2.179", userId="", password="", eventsCoIoT=true]

The item settings (file based) are:

Number Korridor_Motionsensor_Luminance              "Luminanz"                      (luminance)                                                 { channel="shelly:shellymotion:60a423937252:sensors#lux" }
DateTime Korridor_Motionsensor_LastUpdate           "Update"                                                                                    { channel="shelly:shellymotion:60a423937252:sensors#lastUpdate" }
Switch Korridor_Motionsensor_Motion                 "Bewegung"                      (motion)                                   					{ channel="shelly:shellymotion:60a423937252:sensors#motion" }
String Korridor_Motionsensor_Illumination           "Illumination"                                                                              { channel="shelly:shellymotion:60a423937252:sensors#illumination" }
DateTime Korridor_Motionsensor_Motion_Timestamp     "Motion Update"                                                                             { channel="shelly:shellymotion:60a423937252:sensors#motionTimestamp" }
Number Korridor_Motionsensor_Battery                "Cloakroom Motion Sensor"       (battery)                                                   { channel="shelly:shellymotion:60a423937252:battery#batteryLevel" }
Switch Korridor_Motionsensor_Battery_Low            "Ladezustand kritsch"                                                                       { channel="shelly:shellymotion:60a423937252:battery#lowBattery" }

The trace reveals the following problem:

2021-05-25 11:36:54.977 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252: CoIoT Message from /192.168.2.179:5683 (MID=14245): {"G":[[0,6107,1],[0,3119,1621942611],[0,3120,1],[0,6110,0],[0,3106,100],[0,3111,82],[0,9103,25]]}
2021-05-25 11:36:54.978 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel device#heartBeat updated with 2021-05-25T11:36:54.000+0200 (type class org.openhab.core.library.types.DateTimeType).
2021-05-25 11:36:54.980 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Watchdog restarted (expires in 3660 sec)
2021-05-25 11:36:54.981 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252: CoIoT Sensor data {"G":[[0,6107,1],[0,3119,1621942611],[0,3120,1],[0,6110,0],[0,3106,100],[0,3111,82],[0,9103,25]]} (serial=4864)
2021-05-25 11:36:54.982 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252: 7 CoAP sensor updates received
2021-05-25 11:36:54.983 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[0]: id=6107, Value=1.0 (motion, Type=A, Range=0/1;-1, Link=1: sensor_0)
2021-05-25 11:36:54.984 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[1]: id=3119, Value=1.621942611E9 (timestamp, Type=S, Range=U32;-1, Link=1: sensor_0)
2021-05-25 11:36:54.986 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[2]: id=3120, Value=1.0 (motionActive, Type=A, Range=0/1;-1, Link=1: sensor_0)
2021-05-25 11:36:54.988 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[3]: id=6110, Value=0.0 (vibration, Type=A, Range=0/1;-1, Link=1: sensor_0)
2021-05-25 11:36:54.989 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[4]: id=3106, Value=100.0 (luminosity, Type=L, Range=U32;-1, Link=1: sensor_0)
2021-05-25 11:36:54.990 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[5]: id=3111, Value=82.0 (battery, Type=B, Range=0/100;-1, Link=2: device)
2021-05-25 11:36:54.991 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252:  Sensor value[6]: id=9103, Value=25.0 (cfgChanged, Type=EVC, Range=U16, Link=2: device)
2021-05-25 11:36:54.993 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel sensors#lux updated with 100 lx (type class org.openhab.core.library.types.QuantityType).
2021-05-25 11:36:54.996 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel sensors#motion updated with ON (type class org.openhab.core.library.types.OnOffType).
2021-05-25 11:36:54.998 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel sensors#motionTimestamp updated with 2021-05-25T11:36:51.000+0200 (type class org.openhab.core.library.types.DateTimeType).
2021-05-25 11:36:55.001 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shellymotion-60a423937252: 3 channels updated from CoIoT status, serial=4864
2021-05-25 11:36:55.002 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel sensors#lastUpdate updated with 2021-05-25T11:36:55.000+0200 (type class org.openhab.core.library.types.DateTimeType).
2021-05-25 11:36:55.273 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Updating status (refreshSettings=false)
2021-05-25 11:36:55.274 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellymotion-60a423937252: HTTP GET for http://192.168.2.179/status
2021-05-25 11:36:57.840 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellymotion-60a423937252: HTTP Response 200: {
"wifi_sta": {"connected": true,"ssid": "Yggdrasil","ip": "192.168.2.179","rssi": -45},"cloud": {"enabled": false,"connected": false},"mqtt": {"connected": false},"time": "11:36","unixtime": 1621942614,"serial": 0,"has_update": false,"mac": "60A423937252","cfg_changed_cnt": 0,"sleep_time": 0,"actions_stats": {"skipped": 0},"lux": {"value":100,"illumination": "dark","is_valid": true},"sensor": {"motion": true,"vibration": false,"timestamp": 1621942613,"active": true,"is_valid": true},"bat":  {"value":82,"voltage": 3.966},"charger": false,"update": {"status": "unknown","has_update": false,"new_version": "20210226-072307/v1.1.0@f31e1d2b","old_version": "20210226-072307/v1.1.0@f31e1d2b","beta_version": null},"ram_total": 65536,"ram_free": 62820,"fs_size": 65536,"fs_free": 59708,"uptime": 3740,"active/sleep_ratio": 0.00,"ps_mode": 1
}
2021-05-25 11:36:57.843 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel device#heartBeat updated with 2021-05-25T11:36:57.000+0200 (type class org.openhab.core.library.types.DateTimeType).
2021-05-25 11:36:57.844 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Watchdog restarted (expires in 3660 sec)
2021-05-25 11:36:57.846 [DEBUG] [lly.internal.util.ShellyChannelCache] - shellymotion-60a423937252: Channel device#uptime updated with 3740 s (type class org.openhab.core.library.types.QuantityType).
2021-05-25 11:36:57.848 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellymotion-60a423937252: HTTP GET for http://192.168.2.179/status
2021-05-25 11:36:57.917 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shellymotion-60a423937252: HTTP Response 200: {
"wifi_sta": {"connected": true,"ssid": "Yggdrasil","ip": "192.168.2.179","rssi": -45},"cloud": {"enabled": false,"connected": false},"mqtt": {"connected": false},"time": "11:36","unixtime": 1621942614,"serial": 0,"has_update": false,"mac": "60A423937252","cfg_changed_cnt": 0,"sleep_time": 0,"actions_stats": {"skipped": 0},"lux": {"value":100,"illumination": "dark","is_valid": true},"sensor": {"motion": true,"vibration": false,"timestamp": 1621942613,"active": true,"is_valid": true},"bat":  {"value":82,"voltage": 3.966},"charger": false,"update": {"status": "unknown","has_update": false,"new_version": "20210226-072307/v1.1.0@f31e1d2b","old_version": "20210226-072307/v1.1.0@f31e1d2b","beta_version": null},"ram_total": 65536,"ram_free": 62820,"fs_size": 65536,"fs_free": 59708,"uptime": 3740,"active/sleep_ratio": 0.00,"ps_mode": 1
}
2021-05-25 11:36:57.919 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Create missing sensor channel(s)
2021-05-25 11:36:57.921 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Unable to refresh status: Unable to update status
java.lang.IllegalArgumentException: Channel definition for sensors#vibration not found!
	at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions$ChannelMap.get(ShellyChannelDefinitions.java:602) ~[bundleFile:?]
	at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.getDefinition(ShellyChannelDefinitions.java:234) ~[bundleFile:?]
	at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.addChannel(ShellyChannelDefinitions.java:461) ~[bundleFile:?]
	at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.createSensorChannels(ShellyChannelDefinitions.java:422) ~[bundleFile:?]
	at org.openhab.binding.shelly.internal.handler.ShellyComponents.updateSensors(ShellyComponents.java:256) ~[bundleFile:?]
	at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.refreshStatus(ShellyBaseHandler.java:422) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
2021-05-25 11:36:57.924 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: 0 more updates requested

It seems that the status is received by OH, but it won’t update. Does anyone have an idea, what’s wrong here?

@markus7017 Do you have an idea what’s wrong here?

Oliver2 · May 25, 2021, 6:47pm

Hey Marcus,
I just wanna understand your idea why these values are provided via trigger channel and not via state channel

markus7017 · May 25, 2021, 8:46pm

this would mean: one state channel per alarm
= a mess of channels

Mario_Aerni · May 29, 2021, 11:23am

Hi,
@markus7017 could you please take a loot at this posting?
I’m really not sure what’s wrong here:

Thanks in advance!

jeroenvdd · May 31, 2021, 3:27pm

Hi,
i have a wierd bug:
I read the adc voltage from the shelly uni,
and in my ‘item list’ it shows the value,
but when I click the item it shows ‘Err’
when i click analyze to see the graph, it shows the value again…

Mark_VG · May 31, 2021, 3:53pm

I think it is related to this:

github.com/openhab/openhab-addons

[shelly] Shelly UNI - ADC Voltage units of measure missing

opened 06:14PM - 22 May 21 UTC

closed 10:00PM - 15 Jun 21 UTC

Mark-VG

bug PR pending

When the Shelly UNI is configured using all the default Channel and link informa…tion the _VoltageADC state shows as Err in the UI: ![ADC](https://user-images.githubusercontent.com/84638697/119236498-0ae0cf00-bb38-11eb-9f2a-526831e15f69.png) ## Expected Behavior The Item should be created in a way that allows the display of the STATE using the default parameters ## Current Behavior In order to get the STATE to display correctly the metadata for State Description has to be modified to something like ```%.2f V``` This allows the STATE to display correctly (and consistently with the behavior of the Shelly EM: ![ADC2](https://user-images.githubusercontent.com/84638697/119236609-a2462200-bb38-11eb-9d32-4ea87bad40d0.png) This has been discussed on the forum under: https://community.openhab.org/t/oh3-shelly-binding-uom-voltage-vs-temperature-explanation/122624 Seems that on the Shelly UNI the UoM is not included in the state: ``` { "link": "http://localhost:8080/rest/items/ShellyUNIshellyunie8db84d6b3e510163199230_VoltageADC", "state": "27.83", "stateDescription": { "pattern": "%.0f %unit%", "readOnly": true, "options": [] }, "editable": true, "type": "Number:ElectricPotential", "name": "ShellyUNIshellyunie8db84d6b3e510163199230_VoltageADC", "label": "Shelly UNI Voltage ADC", "category": "", "tags": [ "Point" ], "groupNames": [] } ``` Whereas on an EM, the UoM is included: ``` { "link": "http://localhost:8080/rest/items/ShellyEMshellyemb04c0810163199229_Voltage", "state": "232.1 V", "stateDescription": { "pattern": "%.3f %unit%", "readOnly": true, "options": [] }, "editable": true, "type": "Number:ElectricPotential", "name": "ShellyEMshellyemb04c0810163199229_Voltage", "label": "Shelly EM UPS Voltage", "category": "", "tags": [ "Point" ], "groupNames": [] } ``` ## Possible Solution Could the Binding be updated to include the UoM on the Voltage ADC channel, similar to what is done on the Shelly EM? ## Steps to Reproduce (for Bugs) 1. Link the _VoltageADC channel using the default Type (Number:ElectricPotential) 2. View the linked ITEM on the UI ## Context Inconsistent behavior between different Shelly products as well as difficulty for new users who expect that the ITEM will display correctly when configured using the default settings. Requires the addition of Metadata to overcome. Also inconsistent with other linked channels such as Temperature which also do not require additional metadata to work "out the box". ## Your Environment Version used: openHAB 3.1.0.M4 Environment name and version: Java Runtime Azul Systems, Inc. 11.0.9.1 (Zulu11.43+55-CA) Operating System and version: Windows 10/10.0 (amd64

and

jeroenvdd · May 31, 2021, 3:55pm

yep exactly,
I’m on latest DEV build so ‘bug’ is still present

Mario_Aerni · June 1, 2021, 3:22pm

Very well, found the problem.

Missing channel in the code base.

See: openhab-addons/ShellyChannelDefinitions.java at main · openhab/openhab-addons · GitHub

After adding the line:

.add(new ShellyChannel(m, CHGR_SENSOR, CHANNEL_SENSOR_VIBRATION, "vibration", ITEMT_SWITCH))

the newly created snapshot works like a charm.

Opend an issue:

github.com/openhab/openhab-addons

[shelly] Missing Channel Definition for Vibration Events

opened 03:39PM - 03 Jun 21 UTC

ljucam

bug

Incoming CoIoT Events for Shelly Motion lead to the following exception. ```… 2021-05-25 11:36:57.919 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Create missing sensor channel(s) 2021-05-25 11:36:57.921 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: Unable to refresh status: Unable to update status java.lang.IllegalArgumentException: Channel definition for sensors#vibration not found! at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions$ChannelMap.get(ShellyChannelDefinitions.java:602) ~[bundleFile:?] at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.getDefinition(ShellyChannelDefinitions.java:234) ~[bundleFile:?] at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.addChannel(ShellyChannelDefinitions.java:461) ~[bundleFile:?] at org.openhab.binding.shelly.internal.provider.ShellyChannelDefinitions.createSensorChannels(ShellyChannelDefinitions.java:422) ~[bundleFile:?] at org.openhab.binding.shelly.internal.handler.ShellyComponents.updateSensors(ShellyComponents.java:256) ~[bundleFile:?] at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.refreshStatus(ShellyBaseHandler.java:422) [bundleFile:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:829) [?:?] 2021-05-25 11:36:57.924 [TRACE] [y.internal.handler.ShellyBaseHandler] - shellymotion-60a423937252: 0 more updates requested ``` Due to this exception the events from a shelly motion are not processed. As a solution you have to adapt the [ShellyChannelDefinitions ](https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.binding.shelly/src/main/java/org/openhab/binding/shelly/internal/provider/ShellyChannelDefinitions.java#L170) class and add the following line. ``` .add(new ShellyChannel(m, CHGR_SENSOR, CHANNEL_SENSOR_VIBRATION, "vibration", ITEMT_SWITCH)) ``` ## Your Environment Shelly Binding 3.1.0.202105081702

waitz_sebastian · June 5, 2021, 9:16pm

Hey everyone,
I seperated my IOT devices from the default LAN into separate networks, and OH3 is dual-homed on server-LAN as well as on IOT-Wifi. Since OH is also part of IOT-Wifi, theres no routing, etc involved.

But since then, I dont receive any feedback from the device changes. So if light-switch connected to shelly is used, this is not reflected in Openhab any longer.
Guess this has something to do with callback or so. Any suggestions to make this work again?
Thanks for your help.

OH version: 3.1.0 #2415
Shelly 1 FW: 1.10.4
OH3 main IP: 192.168.25.16
OH3 IOT-IP 192.168.31.16
Shelly 1: 192.168.31.208
ICMP works on the correct interfaces

swa@nuc:~$ sudo tcpdump -i eth0.31 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.31, link-type EN10MB (Ethernet), capture size 262144 bytes

23:19:57.575779 IP 192.168.31.16 > 192.168.31.208: ICMP echo request, id 3986, seq 1, length 64
23:19:57.578100 IP 192.168.31.208 > 192.168.31.16: ICMP echo reply, id 3986, seq 1, length 64
23:19:58.577894 IP 192.168.31.16 > 192.168.31.208: ICMP echo request, id 3986, seq 2, length 64
23:19:58.584922 IP 192.168.31.208 > 192.168.31.16: ICMP echo reply, id 3986, seq 2, length 64
23:19:59.580051 IP 192.168.31.16 > 192.168.31.208: ICMP echo request, id 3986, seq 3, length 64
23:19:59.587729 IP 192.168.31.208 > 192.168.31.16: ICMP echo reply, id 3986, seq 3, length 64
23:20:00.581540 IP 192.168.31.16 > 192.168.31.208: ICMP echo request, id 3986, seq 4, length 64
23:20:00.586322 IP 192.168.31.208 > 192.168.31.16: ICMP echo reply, id 3986, seq 4, length 64


swa@nuc:~$ sudo tcpdump -nnn -i eth0.31 "host 192.168.31.208"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.31, link-type EN10MB (Ethernet), capture size 262144 bytes
23:33:02.007701 IP 192.168.31.208.5683 > 224.0.1.187.5683: UDP, length 106
23:33:03.618996 IP 192.168.31.208.5353 > 224.0.0.251.5353: 0* [0q] 6/0/0 PTR _http._tcp.local., PTR shelly1-98F4ABF2A062._http._tcp.local., (Cache flush) SRV shelly1-98F4ABF2A062.local.:80 0 0, (Cache flush) TXT "id=shelly1-98F4ABF2A062" "arch=esp8266" "app=switch1" "fw_version=1.0" "fw_id=20210429-100340/v1.10.4-g3f94cd7", (Cache flush) A 192.168.31.208, (Cache flush) NSEC (483)
23:33:08.519233 IP 192.168.31.16.49457 > 192.168.31.208.80: Flags [S], seq 3589188376, win 29200, options [mss 1460,sackOK,TS val 523286 ecr 0,nop,wscale 7], length 0
23:33:08.524215 IP 192.168.31.208.80 > 192.168.31.16.49457: Flags [S.], seq 11538236, ack 3589188377, win 2920, options [mss 1460], length 0
23:33:08.524329 IP 192.168.31.16.49457 > 192.168.31.208.80: Flags [.], ack 1, win 29200, length 0
23:33:08.525588 IP 192.168.31.16.49457 > 192.168.31.208.80: Flags [P.], seq 1:190, ack 1, win 29200, length 189: HTTP: GET /status HTTP/1.1
23:33:08.545274 IP 192.168.31.208.80 > 192.168.31.16.49457: Flags [FP.], seq 1:889, ack 190, win 2731, length 888: HTTP: HTTP/1.1 200 OK
23:33:08.545379 IP 192.168.31.16.49457 > 192.168.31.208.80: Flags [.], ack 890, win 31968, length 0
23:33:08.546549 IP 192.168.31.16.49457 > 192.168.31.208.80: Flags [F.], seq 190, ack 890, win 31968, length 0
23:33:08.551273 IP 192.168.31.16.49458 > 192.168.31.208.80: Flags [S], seq 3894162916, win 29200, options [mss 1460,sackOK,TS val 523294 ecr 0,nop,wscale 7], length 0
23:33:08.551820 IP 192.168.31.208.80 > 192.168.31.16.49457: Flags [.], ack 191, win 2730, length 0
23:33:08.560163 IP 192.168.31.208.80 > 192.168.31.16.49458: Flags [S.], seq 11559841, ack 3894162917, win 2920, options [mss 1460], length 0
23:33:08.560275 IP 192.168.31.16.49458 > 192.168.31.208.80: Flags [.], ack 1, win 29200, length 0
23:33:08.561790 IP 192.168.31.16.49458 > 192.168.31.208.80: Flags [P.], seq 1:198, ack 1, win 29200, length 197: HTTP: GET /status/relay/0 HTTP/1.1
23:33:08.584473 IP 192.168.31.208.80 > 192.168.31.16.49458: Flags [P.], seq 1:889, ack 198, win 2723, length 888: HTTP: HTTP/1.1 200 OK