Shelly Binding

@markus7017: I have the new “Shelly BLU Wall Switch 4” and “Shelly BLU RC Button 4”, both are identified as “Shelly BLU Button 1” and I receive only from one button the triggered information: from the 4th button always. But no triggered information from 1st, 2nd or 3rd button. And I can not see those new Shelly devices are supported so far. I use 4.2.1 stable, but also in release note 4.3.0 M1 I can’t see they are supported. Is there a way I can fix this issue, or I still have to wait they will be supported.
btw: I have seen with “log:set INFO org.openhab.binding.shelly” the API does send for all buttons events.

@markus7017 .

I start rule A (on) with the notification from “S”, and rule B (off) with an “SS”.
So to change the trigger with the counter channel from the item, will not help, because I cannot separate if the press was a single or a double single.
Rule A send to the Klima a different IR command as rule B with a different IR command.
So,it is not an classic toggle switch…

So I need to know, when a “S” was send and when “SS” was send.
At the moment only the output is given, when a change was done between “S” and "SS”.

Here an example of the rule…


configuration: {}
2
triggers:
3
  - id: "1"
4
    configuration:
5
      itemName: Klimaanlage_Button_Letztes_Ereignis
6
      state: S
7
    type: core.ItemStateUpdateTrigger
8
conditions: []
9
actions:
10
  - inputs: {}
11
    id: "3"
12
    configuration:
13
      itemName: KlimaanlageSchalter
14
      command: ON
15
    type: core.ItemCommandAction
16
​

I guess you need to trigger your rule by a channel trigger, not by item change trigger

The Shelly Button1 has those different outputs by pressing the button in different ways.


SHORT_PRESSED	The button was pressed once for a short time (lastEvent=S)
DOUBLE_PRESSED	The button was pressed twice with short delay (lastEvent=SS)
TRIPLE_PRESSED	The button was pressed three times with short delay (lastEvent=SSS)
LONG_PRESSED	The button was pressed for a longer time (lastEvent=L)
SHORT_LONG_PRESSED	A short followed by a long button push (lastEvent=SL)
LONG_SHORT_PRESSED	A long followed by a short button push (lastEvent=LS)

So only this outputs can be used as a trigger…

Make your rule triggered by „Ereignisauslöser“ and use event values like SHORT_PRESSED, DOUBLE_PRESSED, etc

EDIT: triggering by „Letztes Ereignis“ is the wrong way. This might also lead to unexpected behavior if openhab is restarted and this item is persisted. When the rule engine is up and running and the item changes from null to „S“ to restore the last value, your urule will be triggered without a press of a button.
The triggering channel is the correct way. If you prefer you can also link an item to this channel.

PERFEKT @Oliver2 !!!

I running since 2.x or something OH over couple of years. But this is some totaly new
for me. I was all this years not aware of this:

image

There is behind a new trigger to me “a trigger channel fires”.
WOW, WOW, WOW…

It works now as expected, makes the system more robust, save time and frustation,
from the WAF users…

@Oliver2 : You are the man of the week… Thanks :slight_smile:

1 Like

that’s correct, decoding of button 1-3 is currently not supported for the the 4 button BT switches. I couldn’t find any information how to get additional BT infos including the button states

I’ll add a note to the README

Hello everyone,
I have a question about the Shelly Blu running in Beacon Mode ON.

Shouldn’t I get an update event each time the device reports?

Even with Openhab 4.2.1, I occasionally have a Shelly Blu that does not update its status change. I have set all Blu to beacon mode ON and still the status does not change. However, I would have expected that the beacon mode would also set it to its current state at some point.

With the Shelly BLE debug app, however, I can see that the Blu regularly reports its status.

Best regards
Uli

Translated with DeepL.com (free version)

Thank you @markus7017 : can you check this?

looks like it is updated also for the other buttons.
Thank you

Any updates for Plus Uni

Oh? It’s the UNi not supported? Crap I wanted to use it in my door bell…

Just the „Plus“ Uni. The regular Uni works very well :ok_hand:

1 Like

It is correct, the Shelly uni is working fine but the Shelly plus uni has a problem.
Considering ther is a shelly plus uni I’ would think to use it for new project as they probably not continuing generation 1 devices as the shelly uni.

Ha Markus,

Thanx for the reply and explaination.
I’m using the event trigger channel now, that one updates at every button press regardless of the prior press.

Best regards, Jesse

Hello, I have the same problem as already more people did ask an solution for it.
I will explain as much as i know and i hope for an solution .

  • I had over the years a raspberry PI4 with OpenHAB 3xx til 4.2.0 working fine for many years with plugwise plugs.
  • Last year i did go to an PI5 with OpenHAB 4.2.0
  • After install everything works fine again
  • Then i started with Shelly module’s. Many Plus i4, Dimmer2, Plus 2PM installed in my home.
  • Most of the 2PM are for Rollers ( setup 2PM as Cover)

Final status for 1 month ago was that everything was working fine.

Then i saw that my 2PM did have FW 1.0.7 and I started with update for all Shelly’s to the last stable version 1.4.2.
The most Shelly module’s had no problem with it.
Only the Shelly Plus 2PM, the ones in the OH binding where not seen any more and the ones already working in OH :


But the one i did not update is still working fine

Then i started reading , asking but no result !
Then i started new with one Shelly Plus 2PM with FW 1.4.2
factory reset. as i was started for years ago.

  • factory reset start IP 192.168.33.1
  • By mobile I go to Wifi and set my static IP (192.168.0.36), Sub, GW and DNS SAVE !
  • I dit go to the webpage off the 2PM on 192.168.0.36 and seem OK.
  • Settings : only Wifi !
    image

So after factory reset the 2PM is seen in the web and in the OH binding !

  • The 2PM is standard setting on Switch.
  • all the testings for the 2PM as Switch, seen in the openhab binding , seen in Openhab by things scrips and scheduls are working everything looks fine for me.

BUT THEN : i have to change from Switch to Cover for my Rollers.
I did the changing 2 times again from factory reset because i can change directly in the webpage from the 2PM or later on when it is imported in OH.

1 - Factory reset and the standard settings !

  • 2PM OK in the web

  • Before i changed to Cover, the 2PM is seen in OH binding

  • then i switched the 2PM to Cover and directly the 2PM is disappeared in de OH binding.
    after new scan it stil is disappeared

2 - Factory reset and the standard settings !
The same happen 's if you do not Factory setting but you go back chancing from Cover to switch.

I can not change it to Cover in OH

If i change it in the web than noting happen’s in OH it still is a Switch for OH

The one with FW 1.0.7 is still working that what i need,

Hi everyone,

I just got a new Shelly Pro 2. After setting it up and trying to include it in openhab 4.2.2, I figured out, that auto discovery isn’t able to find the correct device type and the thing is not usable.

CONFIGURATION_ERROR
The IP address of the Shelly device is not configured.

Thing Type:
Unknown Shelly Device

But, I am able to set it up manually by choosing Shelly Pro 2 as Device. So I am able to use the device. But auto discovery is shown that unknown device. After reading some documentations, I figured out, that the Vendor ID of my Device is SPSW-202XE12UL which is not in the documentation and perhaps is not in the list of device for the pro 2 in the bindings code.

I am using the latest firmware 1.4.2 on the Pro 2 in Relay mode and I am using the included binding version from openhab 4.2.2.

Perhaps this issue is related to the 2PM problem and firmware 1.4.2?