Theres no Switch for the Shelly 2.5
I have two of hem in use and can use none of them with this Beta binding. It gets discovered and connects flawless. But there no Switch-Channel for those.
Is there still a difference between the marketplace version and the official version after the PR merged today?
If not, I would recommend to unpublish it from the marketplace as soon as OH 3.4 is released, that will avoid confusion for users,
I still have the problem that the Marketplace version canāt be installed from the UI.
a) Youāll get an unspecific error message in the log that the installation failed or
I suppose that the syntax of the post is not fully correct, maybe you could help here.
b) the problem above, because the Californium dependency, which comes with the core was updated from 2.7.3 to 2.7.4.
My general view
- The Dist is the master, which means last stable version, or last snapshot based on the latest merged PR
- I use the marketplace to publish beta versions from time to time considered stable. The link points to the same jar I publish as the DEV build in the other thread.
Not perfect, but users donāt want to wait until the next PR is merged / a new milestone build is available. We had many new things in the last months, because Allterco introduced a complete new series of devices. I would expect this will slow down in the future.
The current post - maybe you could verify the syntax and give a hint
The **Shelly Binding** integrates the Allterco Shelly Devices. It supports Generation 1 (Shelly 1 etc.) as well as the complete Shelly Plus and Pro Series (Generation 2).
**Features**
* Auto Discovery of connected Shelly devices
* Provide a lot of status data (relay status, power meter, sensor values)
* Some internal device information like wifi strength or internal device temp
* Event trigger, e.g. for pushed buttons
* Control functions like relay output on/off
* Shelly Manager for device configuration and firmware upgrades
See documentation in Resources section for setup.
## Changelog
### 19.11.2022 3.4 M3/M4 (PR# #13520)
- Updated to Californium 2.7.3 coming with OH 3.4 M3 and newer
- Support for new ShellyPlus Add-On
- Support for Shelly1/1PM External Switch Add-On
### 1.10.2022: 3.4 PR4
- includes Plus / Pro support for all new devices (while keeping compatibility for Gen1 devices)
- merge is requested ([PR #13439](https://github.com/openhab/openhab-addons/pull/13439))
## Status and future development.
Feedback is always welcome (do not hesitate to tell if it works !) Share your experiences, creative work or problems in the [Community Thread](https://community.openhab.org/t/shelly-binding). Also ideas and contributions are welcome.
A pull request is pending to merge Plus/Pro support to the official distro (3.4 will be released by end of the year).
Contribution welcome ! There is so much to do :
* Testing with all devices and all setup types
* Description of more use cases so others benefit from your work
* Maybe some nice widgets for Main UI
**Make sure to select the correct bundle matching your installed openHAB release**
The are different builds for openHAB 3.2,, 3.3, 3.4 M1/M2 (supported by the 3.4M2 build)
and openHAB starting with 3.4 M3 (supported by the 3.4M3 build).
You need to install the Californium Soap implementation before installing the binding
1. open OH console and run "feature:install openhab-transport-coap"
2. and then copy the binding jar to the adding folder
The binding supports auto-discovery, there is no need to create .thing files. Maybe you need to scan multiple times to find all devices on your network. Docker users: You need to make sure that the container receives Multicast traffic for generation 1 devices (no Plus/Pro), or configure the device to CoIOT Peer Mode (using device UI or build-in Shelly Manager).
## Resources
[org.openhab.binding.shelly-3.4.0M3-SNAPSHOT.jar (OH 3.4 M3/M4)](https://github.com/markus7017/myfiles/blob/master/marketplace/shelly/org.openhab.binding.shelly-3.4.0M3-SNAPSHOT.jar?raw=true)
[org.openhab.binding.shelly-3.4.0M3-SNAPSHOT.jar (OH 3.2, 3.3, 3.4 M1/M2)](https://github.com/markus7017/myfiles/blob/master/marketplace/shelly/org.openhab.binding.shelly-3.4.0M2-SNAPSHOT.jar?raw=true)
[Shelly API Reference](https://shelly-api-docs.shelly.cloud/?fbclid=IwAR23ukCi_3aBSTPRHYUIcpr0pLi0vcyL0fF0PnJQdFvkkc8_Zo5LkAcli_A#http-server)
[README](https://github.com/markus7017/myfiles/blob/master/shelly/README.md) | [Advanced Use Cases](https://github.com/markus7017/myfiles/blob/master/shelly/doc/AdvancedUsers.md) | [Shelly Manager](https://github.com/markus7017/myfiles/blob/master/shelly/doc/ShellyManager.md)
[Bugs Reports /Feature Requests](https://github.com/openhab/openhab-addons/issues?q=is%3Aissue+is%3Aopen+%5Bshelly%5D)
1 Like
AFAIK, there is an issue with having more than one Link under the ressources tag.
1 Like
Thanks for the great work @markus7017
I got a new Shelly Plus 1PM and it is working great with my openahb 3.4.0-M4 in Docker.
I have a few suggestions for the Outbound websocket functionality.
Outbound Websockets
I do not have any battery powered Gen2 devices so this is not critical to me, but I tried to make it work with the Plus 1PM withā¦ some level of success, I guess 
.
My setup runs OpenHAB in Docker container and behind an nginx based HTTPS reverse proxy.
Both of these (separately or in combination) will break the Outbound websocket functionality.
I have the Outbound websocket set to wss://hab.mydomain.eu:4443/shelly/wsevent with no SSL checks in the web interface.
Going by the WS setup code in checkSetWsCallback() I see that the default URL would not work for this setup and the binding would try to always overwrite it with what it thinks is the correct URL. (luckily it does not, since Plus 1PM is not battery powered)
Docker issues
- By design docker uses private bridged network for containers so the the host IP that OpenHAB sees does not match with the real IP of the machine on the network. This will result in wrong
localIPin the generated websocket URL. - Same goes for port. External port might not match up with port that OpenHAB is listening on in the container.
Reverse Proxy issues
- Proxy often introduces HTTPS so there is need to distinguish between
ws://andwss://in the URL as Shelly will connect to the proxy, not OpenHAB itself. - Connection setup will fail in the onConnect() handler of the socket as the IP of the connection is the IP of the proxy server, not of the Shelly device.
Reverse proxy logs
18:28:00.577 [INFO ] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: INFO: New firmware available: current version: v0.11.4, new version: v0.12.0
18:28:00.578 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1pm-mnv_1pm_ac_defrost: NotifyStatus update received: {"id":889966167,"src":"shellyplus1pm-7c87ce6594c4","dst":"shellyplus1pm-mnv_1pm_ac_defrost","error":{"code":401,"message":"{\"auth_type\": \"digest\", \"nonce\": 1671298081, \"nc\": 1, \"realm\": \"shellyplus1pm-7c87ce6594c4\", \"algorithm\": \"SHA-256\"}"}}
18:28:00.579 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: Initializing device shellyplus1pm-7c87ce6594c4, type SNSW-001P16EU, Hardware: Rev: , batch ; Firmware: v0.11.4 / 20221024-142010
18:28:00.580 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1pm-mnv_1pm_ac_defrost: Thing is not in online state/connectable, ignore NotifyStatus
18:28:00.581 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: Shelly settings info for shellyplus1pm-7c87ce6594c4: {"ble":{"enable":false},"cloud":{"enable":false,"server":"iot.shelly.cloud:6012/jrpc"},"mqtt":{"enable":false,"rpc_ntf":"true","status_ntf":"false"},"sys":{"cfg_rev":30,"device":{"name":"shelly-ac-defrost.mnv.mydomain.eu","mac":"7C87CE6594C4","fw_id":"20221024-142010/0.11.4-ga1906a2","eco_mode":true,"discoverable":true},"location":{"tz":"Europe/Bratislava","lat":0.0,"lon":0.0},"sntp":{"server":"time.google.com"},"debug":{"mqtt":{"enable":false},"websocket":{"enable":false},"udp":null},"ui_data":null,"rpc_udp":{}},"wifi":{"ap":{"enable":false,"ssid":"ShellyPlus1PM-7C87CE6594C4","is_open":true,"range_extender":{"enable":false}},"sta":{"ssid":"mandak","is_open":false,"enable":true,"ipv4mode":"dhcp"},"sta1":{"is_open":true,"enable":false,"ipv4mode":"dhcp"},"roam":{"rssi_thr":-80,"interval":60}},"input:0":{"id":"0.0","type":"switch","invert":false,"factory_reset":true},"switch:0":{"id":"0.0","name":"Odmrazovanie Klimatizacie","in_mode":"detached","initial_state":"off","auto_on":false,"auto_on_delay":60.0,"auto_off":false,"auto_off_delay":60.0,"power_limit":1000,"voltage_limit":280,"current_limit":16.0}}
18:28:00.582 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: Device hasRelays:true (numRelays=1),isRoller:false (numRoller=0),isDimmer:false,numMeter=1,isEMeter:true),isSensor:false,isDS:false,hasBattery:false,isSense:false,isMotion:false,isLight:false,isBulb:false,isDuo:false,isRGBW2:false,inColor:false,alwaysOn:true, updatePeriod:70sec
18:28:00.585 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: Thing successfully initialized.
18:28:00.590 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyplus1pm:mnv_1pm_ac_defrost' changed from OFFLINE (COMMUNICATION_ERROR): Unexpected error: WebSocket connection closed abnormal to ONLINE
18:28:00.759 [DEBUG] [ly.internal.handler.ShellyBaseHandler] - shellyplus1pm-mnv_1pm_ac_defrost: Channel relay#output updated with ON (type class org.openhab.core.library.types.OnOffType).
18:28:00.775 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1pm-mnv_1pm_ac_defrost: NotifyStatus update received: {"id":1252958027,"src":"shellyplus1pm-7c87ce6594c4","dst":"shellyplus1pm-mnv_1pm_ac_defrost","error":{"code":401,"message":"{\"auth_type\": \"digest\", \"nonce\": 1671298081, \"nc\": 1, \"realm\": \"shellyplus1pm-7c87ce6594c4\", \"algorithm\": \"SHA-256\"}"}}
18:28:01.018 [DEBUG] [ng.shelly.internal.api2.Shelly2ApiRpc] - shellyplus1pm-mnv_1pm_ac_defrost: NotifyStatus update received: {"src":"shellyplus1pm-7c87ce6594c4","dst":"shellyplus1pm-mnv_1pm_ac_defrost","method":"NotifyStatus","params":{"ts":1.67129808163E9,"switch:0":{"id":0,"aenergy":{"total":13752.679,"by_minute":[677.734,597.433,597.969],"minute_ts":1671298079}}}}
18:28:07.927 [DEBUG] [yEventServlet$Shelly2WebSocketCreator] - WebSocket: Create socket from servlet
18:28:07.939 [DEBUG] [shelly.internal.api2.Shelly2RpcSocket] - Rpc: Unable to handle connection from 172.23.0.2 (unknown/disabled thing), closing socket
Here on last line you can see that OpenHAB sees internal IP address of the proxy server 172.23.0.2.
The workaround
To skip both Docker and proxy I had to expose the HTTPS port of OpenHAB to be directly accessible from outside on a random port (4443) and set Shelly to connect to this port. This way both proxy and docker are bypassed, along with all the benefits they provide, but hey, it works 
.
Suggestions
-
I would suggest to reduce the URL check only to see if the end of the URL matches with the
/shelly/wseventendpoint and document how to set the URL manually so people can adjust to match different setups. -
When accepting Outbound websocket connection from Shelly, also examine Headers of the HTTP Upgrade request of the
sessionforX-Forwarded-Forheader and extractdeviceIPfrom it if present.
Well, that is a long first post, but want to have this written somewhere if someone is dealing with the same issues.
Thanks again for adding the support for these devices!
@ffr just pinging you, as you seem to had the same docker+proxy issues in the main Shelly thread 
1 Like
I have it working for me, with Docker and Nginx (for external access - I do not use the reverse proxy for access within the local LAN).
The issue for me was the ācall backā from the Shelly to the Openhab server, i.e. the outbound websocket.
I figured out, that the entry in the external websocket field is always set / reset by the binding, so adding a value manually in the Shelly UI does not really solve it.
But by entering the local IP of the Openhab server in the Shelly binding configuration itself (just the IP, no port!) the field on the device gets populated correctly and the device reports status back to the server.
One thought though ā¦ the binding automatically adds port 8080 to the IP that was entered in the binding configuration. I wonder what happens if one uses a different port than 8080 for openhab.
why to use a feature, which is not required for non-battery devices?
the binding currently only supports ws: not wss:
(doesnāt implement SSL handling yet)
The binding detects the local IP from OH network calls. If this is not the right one you could set it manually in the binding settings
how should the binding know this when setting up the url?
the binding takes this info from the OH runtime, it should work if you use a different OH port. White implementing wss: this needs to be adapted using 8443 or whatever is configured in the OH side
Same here with āShelly plus 1PMā and āorg.openhab.binding.shelly-3.4.0M5-SNAPSHOT.jarā in openHAB 3.4. Also missing other channels compared to e.g. āorg.openhab.binding.shelly-3.4.0M2-SNAPSHOT.jarā.
Is this a regression or by intention?
You can delete that addon and simply install the official shelly binding from the builtin marketplace. It got an update a few days ago and supports all PM and Pro devices. Including the right settings for the Shelly 2.5.
1 Like
Thank you! I thought the official shelly binding from the builtin marketplace doesnāt support gen2 devices, but i was wrong. After installation my shelly devices work flawlessly.
Yeah, as i said: There was a major update a few days ago adding support for those devices in the official binding.
Use the binding version include with the 3.4 dist, this is the latest one
This will be better to unpublish this bonding from the marketplace if identical to the onr in the official distribution.
You just to remove a tag.
Iām already working on the next version, which will become a beta build again
@markus7017 : there were several negative feedbacks reported with the OH 3.4 releaseā¦ but also positiveā¦
Could you go through all the messages regarding Shelly binding and OH 3.4?
@markus7017, I get the following error with the beta binding for 3.4.2 when trying to initialize a Pro 3EM.
OMMUNICATION_ERROR
Unexpected error: Unable to create object of type Shelly2DeviceStatus$Shelly2DeviceStatusResult from JSON (syntax/format error: java.lang.IllegalStateException: Expected null but was NUMBER at line 1 column 339 path $.em:0.total_current): {"ble":{},"cloud":{"connected":true},"em:0":{"id":0.0,"a_current":0.726,"a_voltage":240.9,"a_act_power":33.9,"a_aprt_power":174.8,"a_pf":-0.55,"b_current":1.067,"b_voltage":237.9,"b_act_power":162.8,"b_aprt_power":253.7,"b_pf":-0.74,"c_current":0.809,"c_voltage":238.4,"c_act_power":95.3,"c_aprt_power":192.6,"c_pf":-0.66,"total_current":2.601,"total_act_power":292.057,"total_aprt_power":621.023,"user_calibrated_phase":[]},"emdata:0":{"id":0.0,"a_total_act_energy":9782.02,"a_total_act_ret_energy":0.0,"b_total_act_energy":22545.2,"b_total_act_ret_energy":0.0,"c_total_act_energy":20184.03,"c_total_act_ret_energy":0.0,"total_act":52511.24,"total_act_ret":0.0},"eth":{},"modbus":{},"mqtt":{"connected":false},"sys":{"mac":"C8F09E8966D0","restart_required":false,"time":"12:58","unixtime":1.680001083E9,"uptime":442667.0,"ram_size":232136.0,"ram_free":118340.0,"fs_size":524288.0,"fs_free":172032.0,"cfg_rev":11.0,"kvs_rev":0.0,"webhook_rev":0.0,"available_updates":{}},"temperature:0":{"id":0.0,"tC":47.7,"tF":117.9},"wifi":{"sta_ip":"192.168.0.34","status":"got ip","ssid":"Skynet","rssi":-70.0},"ws":{"connected":false}}(class com.google.gson.JsonSyntaxException)
try the updated 3.4.3-SNAPSHOT
3.4.3-DEV Gen1/Plus/Pro | 4.0.0-DEV Gen1/Plus/Pro | README | READMEbeta
Avdanced Users - Shelly Manager - Bugs/Features - API Doc | Firmware Index - Firmware Archive
Note: The DEV build is always newer than the version in the official Distro or Milestone builds
Thanks Markus, now it works. Only thing I noticed is that the Accumulated Total Power channel always stays at 0 kWh.
Best,
Florian
I updated the DEV build to take those values from the device rather computing them from the 3 phases. It requires fw 0.14.1, previous versions do not report total_xxx
See also here: Shelly Binding - #3188 by markus7017
1 Like