Shelly Binding

Add-ons Bindings
,
2823

Hi. Since I upgraded to 3.4.0.M3 the communication with Shelly1 seems one way OH-> Shelly. For example, if I program locally the device in auto off, OH items does not update the status, it stays on.

2824

Hi Markus,
there is internalTemp channel missing for dimmers.
Not important or urgent - just like to let you know.

2825

Hi Markus,

I reported a issue with battery powered Shelly devices after a OH3 (current used versie 3.4.0.M1) restart. There was a link to this page so let me explain again.

My issue is that the button2 and dw2 are not working after a restart. Both devices stay in pending config mode. The only way to get for instance button2 working is attaching a external USB power supply and disable/enable the binding.
Any idea how to solve this? / troubleshoot this?
Or is for this no solution?
All other Shelly devices work perfect after a OH restart.

2826

Isn’t this intended for battery operated shelly devices?
It is the same for my buttons, ht and flood sensor.
They all stay in config pending until the first wakeup.

2827

Yes that is the case but normal events are received and after a restart I don’see any events.

2828

Ive got two Shelly Plus H&T

2829

Not all devices provide internal temp. Usually the binding detects availability of optional properties dynamically. Some of the devices have inconsistent APi structures and need special handling

I need to check why this is not detected

Which firmware are you using?

2830

Check with Shelly Manager if the counter for protocol messages is increasing. If bot post a DEBUG log of the initialization to see if the binding is receiving CoAP events

2831

urg, that‘s an exception in the Californium framework I use to handle CoAP. M3 brings a new version (2.7.3 vs. 2.0) of the jar, which was changed.

I‘m traveling this week and try to find some time at the weekend

2832

Okay thank you very much!

2833

The protocol counter is always zero

2834

Hi all, for some reason there is no registration anymore for triggering SHORT_PRESSED, so my rules arent working anymore.
Did i miss something after an update?
tried to apply eventsPush=true to the thing file, but that didn’t change anything.

2835

Have you changed anything? WiFi, Firmware

Maybe a reboot of the Shelly will help

Greets

2836

The shelly’s got updated a while back, didnt noticed that it didnt work anymore just recent.
Wifi didnt change, and i reboot the shelly a couple of times now, just checked some other 1L that i have same thing, then i tried a 1pm and 2.5, didn’t register it either.
Saw some posts that used eventcount or lastevent, but thats too slow.

2837

In your Event.log nothing?

[openhab.event.ChannelTriggeredEvent ] - shelly:shellyix3:68c63afa98b2:status1#button triggered SHORT_PRESSED

Which openhab version are you using?

2838

correct and dimmer does (and already did in the past).
Using FW version 1.8 and 1.12

2839

I did some research on missing internal temperature channel.

Devices with available internal temperature have the following attributes:

    "temperature": 37.04,
    "overtemperature": false,
    "tmp": {
        "tC": 37.04,
        "tF": 98.67,
        "is_valid": true
    }

whereas dimmers have the following:

    "overtemperature": false,
    "tmp": {
        "tC": 37.04,
        "tF": 98.67,
        "is_valid": true
    }

Don‘t know if it is a bug or by intention that the attribute temperature is missing. However, all devices seem to have tmp.tC

Both devices report the following CoIoT device description (/cit/d):
{"I":3104,"T":"T","D":"deviceTemp","U":"C","R":["-40/300","999"],"L":4}

2840

Hello!

Might be a dumb question, but:
Can I stop Shelly Plugs (S in my case) from reporting Power every 5 seconds (or somehow set the threshold on when they will report?)
They are really spamming my OpenHAB Logs :slight_smile:

Bye, Fridolin.

2841

No, you can’t. Any change of status is logged.
Greetings

1 Like
2842

Thank you!

Bye, Frido.