And also trying to execute from local memory via terminal is not working.
This is not supposed to work.
Did you follow the correct steps ?
First:
open OH console and run “feature:install openhab-transport-coap”
Then download the correct binding .jar to your addons folder.
I guess automatic installation fails cause there are two versions listed.
Thanks for quick reply. I followed your steps.
Automatic installation failed again. What to do next?
And is it necessary to uninstall standard shelly binding? (I think so^^)
And where can I find the ‘correct steps’?
Of course, you first need to uninstall the old binding version.
1 Like
1 Like
Dear Mark, thanks also for prompt reply.
I added the following to /addons:
And tried to install via Openhab web frontend
http://openhabian:8080/settings/addons/marketplace:139554
I just saw, I need to upgrade to Milestone3.4.0.M4
No, you don‘t, there is a version shown working with openHAB 3.3 !
And please, don‘t try to install from marketplace after adding the .jar file to your addons folder. This is not necessary and will produce errors.
You can check if the correct binding is running by entering
bundle:list
on openHAB console.
Hello everyone, unfortunately I also get an error message when starting the binding.
I think you need to update the Californium packages. After much googling, I can’t find a way to do it.
Is there a guide on how to install the binding?
how shall I install the .jar from addons folder?
Just drop it there, openHAB will get it automatically. Please keep in mind, those bindings never show up as installed in the UI.
I do experience the same issue “Installation of add-on marketplace:139554 failed” unfortunately In not very experienced and I can’t solve the issue. I am also not able to download the binding https://github.com/markus7017/myfiles/blob/master/marketplace/shelly/org.openhab.binding.shelly-3.4.0M2-SNAPSHOT.jar?raw=true
I hope to get some hints
Thank you in advanced
How to install in December 2022:
Connect via PuTTy (or something similar) via SSH to your system. Type in
sudo openhabian-config
Navigate to “40 | openHAB Related” select then " | openHAB Milestone" and let the install finish. After upgrading to your Milestone (currently 3.4.0 M5) type following:
ssh -p 8101 openhab@localhost
“habopen” should be the standard password. Type in:
feature:install openhab-transport-coap
Download the add-on using this link:
Place it in the add-ons folder.
Typp
sudo systemctl restart openhab.service
wait for the openhab service to restart and start a scan using the Shelly Binding.
Note: You have to uninstall your Shelly-binding beforehand.
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?