Added ZHA Osram Mini Switch

[noxhirsch]

Blueprint Checklist

• [x] You viewed the README and conformed to the naming conventions
• [x] You ordered the actions as stated in the README action order
• [x] All filenames are lowercase and uses '-' for spaces and not '_' while using {service-name}-{switch-name-or-type}.yaml format
• [x] Images are png
• [x] Image backgrounds are transparent and is cropped to the device boundries
• [x] Images has a maximum width of 800px and maximum height of 500px
• [x] There are no missing buttons or actions
• [x] Your integration/service is running on the latest version
• [x] You have tested your blueprints and made sure each button and action works

[Sian-Lee-SA]

Curious, how does the image represent move to color temp, saturation and hue? Seeing as these are supposed to be configurable for any scenario and the switch image shows no indication for temp, hue, sat would it not be better to name it something more generic? Also shortening the name would be good too as to avoid stretching out the actions tabs (possible remove 'move to' as it would be understood by the owner of the switch what the action refers to.

[noxhirsch]

The button in the middle sends some very weird commands - that's why I decided to keep the original naming.

Short press: Press: move_to_level_with_on_off 1sec after pressing: move_to_color_temp

Long Press: Press: move_to_saturation After 1sec pressing: move_hue Release: move_hue

I assume that the delayed commands are used to send different settings (brightness/hue/saturation) to the connected light in sequence. If you want, I can remove move_to_color_temp and try to filter the move_hue after 1sec pressing. Then we can rename move_hue "press (released)", so that everything is generic - but it goes against "there are no missing [...] actions".

[Sian-Lee-SA]

Yh, I assume those names are like that because if paired directly to a bulb then it would control those options where as using the switch in Switch Manager, they wouldn't be doing that because switch manager doesn't hook into the Zigbee protocol. So if it was coming into Switch Manager then it could be used to control anything so I though something like slide/rotate 1 or A then slide/rotate 2 or B etc. Honestly I'm having trouble picturing how the switch works based on the image so I dunno, if you think how it is is fine then just leave it, I never said to remove actions, just naming and renaming titles to be shorter.

[Sian-Lee-SA]

Problem is that switches are getting more unique and complicated from time to time which makes naming and order a challenge based on the convention stated in the readme. But having the right order and correct actions is more import than renaming titles because that can be changed without issue as the former will cause issues if changed later on.

[noxhirsch]

I think splitting the two move_hue commands make sense - regardless of naming. But then I also have generic names for everything:

• press
• press (delayed)
• hold
• hold (delayed) or rather hold (1 sec) because this event only get triggered if you hold a second or longer
• hold (released) It is a long list, but still shorter than ZHA Philips Hue Dimmer:

The problem I have, is setting the right conditions for move_hue. I looked for examples in the docs, release notes & issues/prs and found that these three conditions should work, but none of them seem do. Can you help me out here what I'm doing wrong?

    actions:
      - title: triggertest1
        conditions:
          - key: command
            value: move_hue
          - key: args.list.0
            value: 1
      - title: triggertest2
        conditions:
          - key: command
            value: move_hue
          - key: params.move_mode
            value: 1
      - title: triggertest3
        conditions: "{{ data.params.move_mode == 1 }}"

this is the event data:

event_type: zha_event
data:
  device_ieee: 00:0d:6f:00:0e:1b:5a:03
  unique_id: 00:0d:6f:00:0e:1b:5a:03:3:0x0300
  device_id: 6658adcc6e3da28041c916b623a1a56c
  endpoint_id: 3
  cluster_id: 768
  command: move_hue
  args:
    - 1
    - 25
  params:
    move_mode: 1
    rate: 25
    options_mask: null
    options_override: null
origin: LOCAL
time_fired: "2023-01-10T20:33:35.247330+00:00"
context:
  id: 01GPEP6SGF4K9WEREKGHVXGQVF
  parent_id: null
  user_id: null

[Sian-Lee-SA]

Are you on latest version? It also should be args.0

[Sian-Lee-SA]

I also dont really understand Hold and Hold (1s) A hold is a hold is it not? regardless if it's 1 second or 3 seconds or even 30 seconds. Same with press delayed, a press is either pressed or it's not?

[Sian-Lee-SA]

And it's not about competing with other blueprints to make it shorter than them, it's just in general it should be short names and skinnier list to help with fitting on screen for mobile devices etc.

[noxhirsch]

Are you on latest version? It also should be args.0

Sorry, I forgot to mention. I tested this with 0.5.3 (and 0.5.2). I also wasn't sure if "list" is necessary or not and already tested with and without.

I also dont really understand Hold and Hold (1s) A hold is a hold is it not? regardless if it's 1 second or 3 seconds or even 30 seconds. Same with press delayed, a press is either pressed or it's not?

"press (delayed)" is triggered 1sec after you (short-)pressed the button. If you hold the button for a few hundred milliseconds (I don't know the exact timing) "hold" gets triggered. If you keep it hold for another second "hold (1s)" gets triggered. So if you hold the button for maybe half a second you get the events "hold" & "hold (released)". If you hold the button for 2 sec you get the events "hold", "hold (1s)" & "hold (released)".

[Sian-Lee-SA]

Try 0.5.5, I tested your conditions myself and the reason it wasn't working was because the key list was erroring out as it wasn't a number so that has been fixed but I can assure you that args.0 works and not error out. The error also causes the other tests to not to be processed.

[noxhirsch]

Thanks, I now tested 0.5.5, but it still does not work for me. I can see the events coming via the HA event viewer, but nothing lights up in Switch Manager except "hold". These are the condition I tested:

      - title: hold
        conditions:
          - key: command
            value: move_to_saturation
      - title: test 1
        conditions:
          - key: args.0
            value: 1
      - title: test 2
        conditions:
          - key: args.0
            value: "1"
      - title: test 3
        conditions:
          - key: params.move_mode
            value: 1
      - title: test 4
        conditions:
          - key: params.move_mode
            value: "1"

If it works on your side and you don't see any mistake when you compare it with the event data, it must be something with my HA instance. Do you have any idea what I can look for? Didn't find anything relevant in the debug logs.

[Sian-Lee-SA]

Could you send the full blueprint with the tests and the event output and that'll give a one to one test

[Sian-Lee-SA]

Also if there is no error in HA logs then all should be good, I would also just make sure you do a hard refresh and clear cache just in case and obviously restart Home assistant if you hadn't done so already, especially on updates

[Sian-Lee-SA]

Also for reference. I did the following to a dummy blueprint and they all fired when I sent thesame event data you posted above

buttons:
  - x: 2
    y: 2
    width: 189
    height: 159
    actions:
      - title: triggertest1
        conditions:
          - key: command
            value: move_hue
          - key: args.0
            value: 1
      - title: triggertest2
        conditions:
          - key: command
            value: move_hue
          - key: params.move_mode
            value: 1
      - title: triggertest3
        conditions: "{{ data.params.move_mode == 1 }}"

[noxhirsch]

I tested the dummy blueprint - triggertest 1 & 2 didn't work, but triggertest3 did work this time. So I updated the Osram MIni Switch blueprint to use the template and it works - then I also updated this PR. Since triggertest1 & 2 work for you, I have to check what's wrong with my HA instance, but I don't have enough time at the moment for that.

[Sian-Lee-SA]

Thanks!

[djdobs]

Would it be possible for this switch (OSRAM mini switch) to be made available for Zigbee2MQTT also please? Or should I create a new pull request? I would be incredibly grateful if this was possible! Thanks

[Sian-Lee-SA]

You would just need to adapt this blueprint to a Zigbee2MQTT format. Copy it then just change some off the properties to match that of a Zigbee2MQTT blueprint. I don't do blueprints for devices I don't own because it just causes too many problems and things can't be tested on my end to be "public" worthy. I also dont think this author has two zigbee services running so him having Zigbee2MQTT to test for the Osram Mini Switch would be a long shot but I could be wrong.

[djdobs]

Ok understood, I'll give that a go and see how I get on! Many thanks