am I the only one, where the door/window 2 sensor is not working anymore. I am now on openHAB 4.1.1 with release binding version 4.1.1. Now my HT Plus devices are working again, that’s great, thanks for that, but my window sensors are still not working.
Someone has an idea, how to fix this? MQTT is not an option here, because this will disable the cloud control of the devices.
No, the format has changed and the script getting installed by the binding rrequires 1.10+
what does that mean? Please provide more details and a DEBUG log
Make sure the device has the latest firmware
Please provide a DEBUG log showing the complete initialization for the device
just wanted to know if the problem is on my side or others have the same after upgrading.
Latest Firmware is installed. Problem here is, that I do not get an item update from the thing. I did a factory reset of the sensor → configured everything from scratch → tried to add the sensor as thing via scanning for devices → after scan failed, I added it manually and thing goes online → added an item for open/close → but nothing updated when the window is open or close. Sensor gets the right state, which is shown in the mobile app.
What kind of debug log you like to see? From openHAB?
You need to push the button and then start Scan, maybe more than once. If the DW2 doesn’t show up on discovery something is odd.
Thank you for explaining.
After trying again and again, bindings auto discovery found my device. I added it as Thing, it was getting online, all channels also are there. I created a test item on channel open/close.
But the item is not getting any updates. Attached you can see the whole log of the Device.
In shelly manager nothing increases. All values are at 0.
shellydw2.log (15.9 KB)
I think, that the device is not able to call the openhab server. I do not know how the communication is working. But perhaps someone can explain, what is happening on the shelly, when the sensor gets a state update from close to open.
After playing around and reading the documentation of the binding, I found a way how it is now working. I hardcoded the CoIoT peer address. Now it is working. A Multicast problem shouldn’t be the problem in my network, because autodiscovery of the devices is working.
Thanks for the help!
Are you running OH in a Docker environment?
Discovery is done by mDNS, events are coming in via CoAP/CoIOT. Peer mode is a good choice if there are not multiple hosts on the network
Yes it is a docker environment. But openhab container is using hosts network directly. I am using a separate wifi/vlan for the shelly devices, but mDNS is working through this network and the network of OH. Peer mode is working, now I just have to remember that, when I am changing something on the network side.
cheers
Andreas
mDNS is standard UDP-based, CoAP is Multicast IP
now things getting clear! So I think I have to use the peer mode, because I am using a different network and I disabled Multicast Enhancement for the IoT network. Perhaps I will try to enable it and check if CoAP is working then with multicast.
Thanks a lot for explaining.
Thanks Markus for the tipp with the debug file.
Meanwhile I received a new orded DHT22 sensor.
This version now connected and the thing new created and works. The items are created and it is working.
It seems, that this first orderd AM2302 was not working. Now I have the values and can replace the
HT in the garden with an shelly plus 1 with the AddOn Modul and the given DHT22 sensor.
Thanks for the support.
BR
PS: When adding the shelly plus 1 with the attached AddOn module WITHOUT an sensor, the created thing in OH4.1, make trouble, ist not recordnized etc…
→ So when adding an AddOn Module with an shelly1 etc, ALLWAYS put first the sensor to the AddOn Module that it works…
good to hear
Could you please provide a DEBUG log of this situation?
I have a problem with my persistent data of the power usage. When the consumption goes to zero, it is not shown in my graphs. I opened up this ticket:
https://github.com/markus7017/myfiles/issues/19
@markus7017 is it better to open up tickets in the openhab/addons repositor? Shall I move it?
here is a screenshot of the behavior out of grafana:
what does than mean? I see the line at 0W
What is the value, which is reported by the binding at that time? Do you see 0W in the channel?/item?
Check events.log to see updates processed by the framework
It is hard to see, but the line is not at 0. It ended up with the last value reported at about 0,8.
The Item and the Binding is reporting 0W, that is totally fine. But perhaps have a look at the ticket screenshots, from my opinion the bug should be visible there.
I will also check the event.log. Thanks for the hint.
If the Binding and Item report 0W, there is no issue in the Shelly Binding but your persistence/Grafana setup.
Please check the according values in your persistence database.
How is your persistence strategy configured ?
I think that could be the problem! I write only every 30s into the persistence, so if I get the latest over 0 value and I power down the connected shelly device within the 30s, the 0 value will not be written to the database. And shelly devices will not sent another 0, because nothing is changing on the consumption. My fault 
Thank you both for your help!
Here is my persistence configuration:
configurations:
- items:
- "*"
strategies:
- everyUpdate
- restoreOnStartup
filters:
- 30seconds
- NULL_UNDEF
cronStrategies: []
defaultStrategies:
- everyUpdate
- restoreOnStartup
thresholdFilters: []
timeFilters:
- name: 60seconds
value: 60
unit: s
- name: 365days
value: 365
unit: d
- name: 30seconds
value: 30
unit: s
- name: 15seconds
value: 15
unit: s
equalsFilters:
- name: NULL_UNDEF
values:
- UNDEF
- "NULL"
- "null"
- undef
inverted: true
includeFilters: []
The issue with Shelly…
After I have received my 2nd. Shelly PLUS HT I decided, to update the existing and the new one to the latest firmware. Booth have now 1.1.1 from the 05.01.2024. Booth are powered by USB.
It looks like, that after a reboot from the 4.1.1-1 OpenHABian installation’s (include offical binding), or a complete reboot from the different PI4 systems, the Thing (Shelly plus HT) will not more come ONLINE.
I have all the time to reset the Shelly plus HT, to bring them online to the OH system back.
So i assume, this have something to do with the new firmware for the HT plus.
@markus7017: Are you aware, that shelly has something changed here, that when the HT plus wakes up, the configuration is not send out to the OH4 systems anymore?
With the older firmware it was no problem to shutdown the OH service and restart and to have after 10 min the HT plus reporting back…
Thanks in advanced.
Correction: It come back automatic, but after serveral hours… not after the next wakeup from 10 min, normal
