Yes, that‘s part of the clean cache to remove not required components.
Best way is to use a batch/sh file which cleans the cache and reinstalls the components
/usr/bin/ssh -p 8101 openhab@localhost feature:install openhab-transport-coap
Im using this file in the /bin/ share
#!/bin/bash
echo '###########################################'
echo '###### openHAB CACHE/TMP loeschen #####'
echo '###########################################'
date "+%A %d/%m/%Y %H:%M:%S"
echo '###########################################'
# openHAB Service stoppen
echo 'Stoppe openhab-Service'
sudo systemctl stop openhab.service
# CACHE und TMP löschen
echo 'CACHE und TMP loeschen'
sudo yes | openhab-cli clean-cache
# openHAB Service starten
echo 'Starte openhab-Service'
sudo systemctl start openhab.service
How do I have do handle your command? Do I have to use „sudo“ as well?
Add the command after starting openhab.service
I don‘t think you need sudo.
Yes, my question was not related to the position in the script but as it is a command of the karaf console I am not sure how this command must look like in a shell script.
1 Like
I added my first Shelly BLU button to openHAB (3.4.5 + DEV Binding 3.4.5.202308121445). Following the docs from the binding everything went fine after some trial and error.
[INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'shelly_button.things'
[WARN ] [core.thing.internal.ThingManagerImpl] - The model of shelly:shellyblubutton:BLUETOOTH_MACADDRESS is inconsistent [thing.getHandler().getThing() != thing]
==> /var/log/openhab/events.log <==
[INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'shelly:shellyblubutton:BLUETOOTH_MACADDRESS' changed from UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {deviceAddress=The parameter is required.} to INITIALIZING
Didn’t find a text file example, so here is one:
Thing shelly:shellyblubutton:BLUETOOTH_MACADDRESS "Shelly BLU button Red" @ "Zolder" [deviceAddress="BLUETOOTH_MACADDRESS"]
Gives a warning about an inconsistent model though? But is working fine:
shelly:shellyblubutton:BLUETOOTH_MACADDRESS:status#button triggered SHORT_PRESSED
Things seems to be silent, but we are working in the background.
Short update on PRs
- PR#15798 fixes a critical resource leak for Gen2 devices, which happened when thing initialization of device discovery resulted in an exception, In this case the WebSocket was not closed and/or the thread got blocked. In combination with a firmware bug of Shelly Wall Display 1.2.4 (current production release!!!) this caused rapidly growing number of threats and opened WebSockets leading into an out-of-memory. Various people help to isolate the problem and testing the fix (see https://community.openhab.org/t/oh4-runs-out-of-memory), kudos to all of them. In addition an IPv6 mDNS discovery caused also an exception if IPv6 is enabled in the OH network config. Same result: Every incoming mDNS request raising open sockets and threads. The PR is also considered to be merged into 4.0.
- PR#15898 This PR implements Auth for Gen2 starting with firmware 1.0 (implementation reworked to implement RFC-based digest auth). In Addition basic auth for Gen1 was changed to avoid exposing credentials when not requested by the device. And device discovery was improved to avoid duplicate things in the Inbox when using .things definitions.
- PR#15922 is in the making, will include small fixes and another round of hardening on the resource topic. Having firmware 1.2.4 on the Wall Display makes it easy to reproduce so I spend some time to do further optimizations. @Lolodomo is doing a great job on reviewing all that stuff.
We need 2 more PRs to get the list up to the DEV level before I continue implementing new features
- Automatic upgrades for the channel definitions. 4.0 brings in stricter checking of channel units and value updates, which shows some inconsistencies in the binding. I changed various channels to use system defined ones (incl. unit definitions) and also implemented a mechanism, which auto-upgrades existing thing/channel definitions when starting the new binding.
- Support for Shelly Plus Dimmer 10V has been added
- and finally I’m working on the proxy device mode (one Shelly uses another one as a hub), but this is work in progress
Said that:
- The first 2 PRs are critical to all users, you should upgrade the binding as soon as a new OH release becomes available
- Firmware 1.2.4 for Shelly Wall Display ist buggy, don’t use it. The problem occurs even you didn’t included the Wall Display as a thing, because it continuously sends mDNS announcement, which are picked up by the binding and processing those causes the out-of-memory. Stay on 1.2.3 or move to 1.2.5-rc6 beta (or 1.2.5 final when it becomes available)
- Please be patient a few more days. I’m working with @Lolodomo to bring all PRs into the code base for the next OH release and postpone implementation of new features or integrating new devices until then.
The best thing you could contribute is testing. I’ll update the DEV build to include the changes from the review process and let you know.
6 Likes
Hello Markus,
thank you for your efforts.
If you have time, could you please also check the following error.
Yesterday I installed a shellyplus1 with the plus-addon. According to the documentation 5 temperature sensors are supported.
This also works in the Shelly app, but in Openhab I can add a maximum of 3 temperature sensors.
Yes, I have read that I could integrate sensors 3 and 4 via MQQT, but I don’t think that’s a clean solution.
Maybe you can fix this error please.
Thank you!
I updated the DEV build for 4.1-SNAPSHOT. Due to changed package dependencies this will no longer work on 4.0.
This version includes the latest functions and changes from PR review. It would be great to get some feedback = testing to make sure having a solid basis moving forward.
WD users fyi: I’m still investigating the Wall Display with @igi Even with firmware 1.2.5 we see tons of mDNS advertisements, which are processed by the binding without NPEs or resource leaks (which is great), but also creates a lot of useless traffic. Who else has a WD with 1.2.5 and wants to share observations (run Wireshark and check frequency of mDNS traffic)?
which version of the binding are you using? DEV build?
no, I’m using 4.0.4.
ok, I created a DEV build for 4.0.x. In general 4.1 would work, but there are various new dependencies (package versions installed by core framework), wich are not fulfilled by 4.0.5
Check READMEbeta how to install this, create a DEBUG log
4.1-DEV | 4.0.-DEV |3.4.5-DEV | 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. Current development is based on 4.1-SNAPSHOT, 4.0.x and 3.4.x might be outdated.
Please make sure to report bugs or feature requests here
This gives me a to-do list once I’m done with the current PRs and you an overview what’s already know / on the list
ok, I’ll give it a try. thanks for the quick support!
Hello everyone,
I have a problem again.
I have integrated quite a few Shelly products into Openhab and have never had any problems.
However, I now have my first Shelly Plug S and can’t get it into Openhab.
The Thing always stays on:
Status:
UNKNOWN
CONFIGURATION_PENDING
Initialisierung oder Gerät im Schlafmodus.
I use Openhab 3.3.0 and the Shelly Binding. The Plug S has the latest FW.
The plug works perfectly in the Shelly app.
I have tried it both with and without the Shelly Cloud access data. Both ways had the same result.
I have also activated MQTT and snooped in my broker (which runs in Openhab) and can find the Shelly there accordingly. However, as I currently only use MQTT to read data and use all other shellys via binding, I actually want to do the same with Plug S.
What’s also strange is that I can’t find the Shelly in the Thing system after the scan, whereas this is the case with all other Shellys. I have to select the Plug S manually and enter the IP. It is also strange that in Thing only the two channels for the device status are offered, but not the others from the relay area.
To be on the safe side, I have already assigned a fixed IP via the Fritzbox and set the Shelly to factory settings. All without success.
Does anyone have any ideas what else I could try?
All of that os not nessesary (no mqtt, static ips…)
The Plug S should be discovered automatically and supported by the binding. However, when I read „OH 3.3.0“ I‘m not sure if that version is supporting that device, because it‘s really old.
Why are you not moving to 3.4.5 or even better to 4.0 (which brings in some migration effort)?
Otherwise you should enable DEBUG log and get additional information, most likely an init problem
1 Like
Thanks, I updated to 3.4.5 and it’s working now.
Unfortunately my shelly flood is now behaving the same way as the Plug S did before 
PS
I dont move to OH4 at the moment as I have a binding running which is very important for me which isn’t working on OH4 anymore.
You need to press the button on Shelly Flood. Then start the discovery in OH, maybe you need to do this 2-3 times.
Good news:
PR #15922: Misc changes (small fixes, log improvements, hardened leak prevention on and
PR #15950: Support for Shelly Plus Dimmer 10v
have been merged, thanks @Lolodomo
Only one more is missing to get the list to the feature level of the DEV build: This includes auto-upgrade of channel definitions. OH 4.1 introduced more strict validation of channel units and updates to channels, which brought up several issues around channel definition and updates. This PR will bringt an auto-update: beside missing channels, which will at added at thing initialization time the binding also checks existing ones if they match the current definitions, if not the definition will be updated.
If you want to help testing: I created a pre-PR build having those changes:
org.openhab.binding.shelly-4.1.0-SNAPSHOT_pr.jar
Once this PR is merged I could work on additional features / bug fixes.
Please make sure to create an issue here
I updated the DEV build for 4.1 and 4.0.5, not 3.4.5
details can be found here:
In addition it includes 2 changes where I need feedback from you
- I removed a dependency in the 4.1 build. Please install and check if the add-on loads immediately (or delayed)
- I change the WebSock interface, which seems to fix a problem with Wall Display not sending sensor updates (or sensor gets only updated once per minute and status poll)
Re Wall Display:
- The production firmware version 1.2.4 contains a bug, which prevents the thing to initialize. Allterco has fixed this in 1.2.5-rc6 and newer. Don’t use firmware 1.2.4, we can’t say anything on versions between 1.0.8 and 1.2.4. If you have 1.2.4 give the current beta a chance, which also brings support for the thermostat feature
- In some installations we see rapid mDNS announcements (@igi does, not with mine). In older builds of the binding this lead to exceptions and out-of-memory, which have been fixed in between. But each mDNS announcement will be processed by the binding and causes unnecessary overhead. So far we couldn’t narrow this down, but are in investigation with the Allterco team.
- In my setup I see the WD web server dying after a while, not accepting any http requests incl. Web UI in a browser. This is not a binding related problem, known by the firmware team, but so far no reason/fix.
Please help to validate the above mentioned changes and share details if you are also bothered by the WD issues listed above.
4.1-DEV | 4.0.-DEV | 3.4.5-DEV | 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. Current development is based on 4.1-SNAPSHOT, 4.0.x and 3.4.x might be outdated.