Shelly Binding

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

markus7017 · June 5, 2021, 10:02pm

@Mario_Aerni @jeroenvdd @Mark_VG Please check the updated DEV builds. Make sure to select the correct jar
3.0.3-SNAPSHOT for OH 3.0, 3.1M1…M4 only
3.1.0-SNAPSHOT for OH 3.1 starting M5 only

Latest DEV builds: 3.1M5+ (current), 3.0.x (3.0.x, 3.1M1…M4) or 2.5.13 (no longer maintained) - README - Installation - Avdanced Users - Shelly Manager - Bugs/Features - Firmware Index - Firmware Archive - API Doc

Oliver2 · June 6, 2021, 5:59am

I had a similiar situation. For any reason OH3 added a second ethernet adapter. Communication from shelly to OH server was fine. But the binding tried to establish a CoIoT connection through the 2nd adapter. So I think you are right in your opinion about the cuse.
However, I was not able to find a solution and put my effort in removing the 2nd adapter.
Have you enabled CoIoT?
What does the log say? Are there any Warnings that CoIoT could not established?
open shelly manager and set CoIoT to peer mode and see which IP address the binding is suggesting.

markus7017 · June 6, 2021, 7:15am

Did you set the IoT IP address in the binding’s config? There is bo CoIoT connection, the protocol is stateless. The binding just listens to a specific UDP port. You could also tr to set the Shelly to CoIoT Peer mode using Shelly Manager. Check the DEBUG log for inbound CoIoT traffic.

Mark_VG · June 6, 2021, 8:16am

Hi Markus

Thanks for this.

I am running on 3.1.0.M5:


                           _   _     _     ____
   ___   ___   ___   ___  | | | |   / \   | __ )
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/
       |_|       3.1.0.M5 - Milestone Build

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

I have uninstalled the Binding via the UI and copied the .jar file to the addons folder.

I get the following error with the 3.1.0-SNAPSHOT for OH 3.1 starting M5 only build

09:50:40.138 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/C:/openHAB/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [274]
  Unresolved requirement: Import-Package: org.eclipse.californium.core; version="[2.0.0,3.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

Also think I have the correct bundles (from what I have read above):

openhab> bundle:list |grep Cali
275 | Active |  80 | 2.0.0                 | Californium (Cf) Core
276 | Active |  80 | 2.0.0                 | Californium (Cf) Element Connector
277 | Active |  80 | 2.0.0                 | Californium (Cf) OSGi

EDIT: I see these are removed when the binding is removed via UI. So I have copied the the two JARS from you files to the addons folder and still not showing up?

EDIT: Sorry, I managed to resolve this. I redownloaded the .JAR files via your download RAW option above (not from your MYFILES) and copied to addons again and they installed.

Any suggestions?
Thanks
Mark

markus7017 · June 6, 2021, 8:51am

check the How-To Install (that’s what it’s made for😙)

Mark_VG · June 6, 2021, 8:53am

Thank you Markus. Other than my hiccup with the manual requirements this is working well.

One small thing you MAY want to consider is to allow the full voltage value to be displayed?

It is currently set to %.0f %unit%, however the device reports with 2 decimal places, so that may be a preferable default setting?

markus7017 · June 6, 2021, 9:27am

try updated build for 3.1M5

Mark_VG · June 6, 2021, 9:48am

I get the following with the latest version:

11:44:37.519 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/C:/openHAB/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [286]
  Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

markus7017 · June 6, 2021, 10:05am

try

delete jar, wait a min
stop OH
run openhab-cli clean-cache
start OH, wait 2min
copy new jar into addons folder

Mark_VG · June 6, 2021, 10:27am

Hi Markus

Still the same:


12:25:41.573 [WARN ] [org.apache.felix.fileinstall         ] - Error while starting bundle: file:/C:/openHAB/addons/org.openhab.binding.shelly-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.shelly [270]
  Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]

I am running on Windows 10, so had to manually delete the /userdata/cache and /userdata.tmp folder contents.

If I put the previous file in addons all works.

markus7017 · June 6, 2021, 11:09am

I did a rebuild, please try again