[BUG] Issues with E1810 Controller

[jrbenito]

Bug report

Smoth power on does not work with Zigpy and E1810.
Brightness long press does not increase/decrease brightness with E1810
Both features works with E1473 on the same lighs

Sorry for report this again, I finally had sometime to try various combinations and try sort this out.

Description

This is same as #24 but now, I have more information.

Smooth power on does not work with E1810 controller. I have two of them, assigned to two different set of lights but both do not work with smooth power on.

Behavior:
all single press works (toggle lighs, bright up/down and change color temp).

• lights off, single press to bright up, turn light on with minimal bright.
• lights off, single press to bright down, does nothing
• lights off, single press to left, does nothing
• lights off, single press to right, does nothing

All long press does not work.

• lights on, minimum brightness, long press to bright up button, does nothing. Expected to bright up continuously
• lights on, maximum brightness, long press to bright down button, does nothing. Expected to bright down continuously
• lights on, middle of color temp scale, long press to left or right buttons, does nothing. Expected to change color temp continuously.

With controller E1743:

• lights off, long press up, smooth turn on
• lights on, long press up, continuously bright up
• lights off, long press down, nothing happens
• lights on, long press down, continuously bright down

Additional information

Notice that light.kitchen_master is a light group. We already talked about that light.group might not work, but it works with E1473 controller. I also changed the above to a single light device and group of lights (instead light group). All configurations presented same behavior.

• Devices involved:
  • Model: E1810 (presenting issues)
  • E1473 working as expected
• Integration: Choose from zha with bellows for radio interface
• AppDaemon version: 4 0.2.1
• ControllerX version: 2.3.1 (hand installed
• Home Assistant Core version: v0.106.1

AppDaemon app configuration

kitchen1_controller:
  module: controllerx
  class: E1810Controller
  controller: cc:cc:cc:xx:xx:xx
  integration: zha
  smooth_power_on: true
  light: light.kitchen_master

kitchen2_controller:
  module: controllerx
  class: E1743Controller
  controller: 14:b4:57:xx:xx:xx
  integration: zha
  smooth_power_on: true
  light: light.kitchen_master

Logs

2020-02-28 16:27:09.144879 WARNING AppDaemon: ------------------------------------------------------------
2020-02-28 16:27:10.149001 WARNING AppDaemon: ------------------------------------------------------------
2020-02-28 16:27:10.150253 WARNING AppDaemon: Unexpected error in scheduler loop
2020-02-28 16:27:10.151342 WARNING AppDaemon: ------------------------------------------------------------
2020-02-28 16:27:10.152895 WARNING AppDaemon: Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/appdaemon/scheduler.py", line 421, in loop
    next_entries = self.get_next_entries()
  File "/usr/lib/python3.8/site-packages/appdaemon/scheduler.py", line 335, in get_next_entries
    next_exec = datetime.datetime.now(pytz.utc).replace(year=3000)
ValueError: day is out of range for month

This log started to happen today, don't think it is related to the problem.

• There are no logs from the ZHA when long presses are done with lights off.

• With lights on, ZHA emits:

2020-02-28 16:30:19 WARNING (MainThread) [zigpy.zcl] Data remains after deserializing ZCL frame
2020-02-28 16:30:22 WARNING (MainThread) [zigpy.zcl] Data remains after deserializing ZCL frame

One at the start of the long press, another on the release. Nothing more (I set log leve for debug).

Additional Context

Thanks for your good work. If you need any other information, I will gladly provide.

Best regards.

[sreknob]

2020-02-28 21:45:21.696243 WARNING AppDaemon: Unexpected error in scheduler loop
2020-02-28 21:45:21.696400 WARNING AppDaemon: ------------------------------------------------------------
2020-02-28 21:45:21.696631 WARNING AppDaemon: Traceback (most recent call last):

File "/usr/local/lib/python3.8/site-packages/appdaemon/scheduler.py", line 432, in loop
next_entries = self.get_next_entries()
File "/usr/local/lib/python3.8/site-packages/appdaemon/scheduler.py", line 344, in get_next_entries
next_exec = datetime.datetime.now(pytz.utc).replace(year=3000)
ValueError: day is out of range for month

I don't think error this scheduler error anything to do with controllerx.

Scheduler errors started showing up in my appdaemon log as well all of a sudden.

Start up appdaemon with my controllers commented out, still getting the error. However, controllers function fine.

Going to do some digging....

[sreknob]

Turns out there is something strange going on with the quirk.

The mappings for hold up and hold down have different args than previously all of a sudden.

Hold up now generates [0, 84] rather than [0, 83] as expected....

I don't see a change in the device handlers for this on the upstream repo so not sure what's going on yet....

[sreknob]

@jrbenito - I just confirmed it's only because of the new args. Still need to figure out why they've changed to see if we need to change them in ControllerX. On the zha-device-handlers repo there are a couple of versions of quirks for the 5-button remote but none of them have different args.
If it's going to stay that way we can update the mappings. I'll ask the zha guys.
In the meantime, using a custom mapping should work as expected for you.

kitchen1_controller:
  module: controllerx
  class: E1810Controller
  controller: cc:cc:cc:xx:xx:xx
  integration: zha
  smooth_power_on: true
  light: light.kitchen_master
  mapping:
    "toggle": "toggle"
    "step_with_on_off_0_43_5": "click_brightness_up"
    "step_1_43_5": "click_brightness_down"
    "press_257_13_0": "click_color_down"
    "press_257_13_0": "click_color_down"
    "press_256_13_0": "click_color_down"
    "move_with_on_off_0_84": "hold_brightness_up"
    "move_1_84": "hold_brightness_down"
    "hold_3329_0": "hold_color_down"
    "hold_3328_0": "hold_color_up"
    "stop": "release"
    "release": "release"

[sreknob]

Also, while I was looking at this, I realized we don't have a mapping for a long hold of the centre button. On ikea bulbs it sets to them to their default color temp and to on. @xaviml is that implemented anywhere?
A long press generates:
toggle right away, followed by release then move_to_level_with_on_off_254_0 then press_2_0_0 all in quick succession after the centre button is held for 3 seconds.
We could use move_to_level_with_on_off_254_0 as a trigger for on_full_brightness and press_2_0_0 for default colour temp. Is this what of_full_color_temp does?

Perhaps could implement a default_color_temp somehow, perhaps customizable by setting it with an x_y colour as a controller option.

[sreknob]

@jrbenito did you turn on ota_update recently?
firmware 1.2.223 gives the expected [0, 83] [1, 83]
firmware 2.3.014 gives [0, 84] and [1, 84]
I just checked with the zha dev and he is aware of it and going to try and find a solution.
For now, I'm going to put in a PR that will work with both firmware versions as a fix.

[sreknob]

Scheduler errors started showing up in my appdaemon log as well all of a sudden.

a fresh pull of the dev tag of appdaemon has resolved this for me.

The issue discussed here

[jrbenito]

@jrbenito did you turn on ota_update recently?
firmware 1.2.223 gives the expected [0, 83] [1, 83]
firmware 2.3.014 gives [0, 84] and [1, 84]

Yes, all my devices were updated by OTA. So the firmware upgrade did broke things.

Thanks for all of information you gathered, I am learning a lot here.

[jrbenito]

Btw, is there a easy way to get firwmare version from the IKEA devices?

[htvekov]

@sreknob
Good idea with the suggested use for hold on centre button.
With a 3 second delay on that hold to trigger, it's hard to use it for anything else.
Except in HA for light/switch groups turn off complety (leaving house).

using z2m, there's just one 'toggle_hold' trown after 3 seconds.

[sreknob]

@jrbenito yes, super easy to get the firmware version in zha
Fire up the zha panel and select your remote. Then select Clusters->Basic. Then below under cluster attributes select “sw_build_id”. Hit “GET zigbee attribute” and hit a button on your remote to wake it for the query. It will display you current version there.

@htvekov I will update the PR with the long hold for zha. Not sure how to handle setting to a specific/default color temperature value.
When paired directly to a bunch of bulbs and switches in Tradfri it’s super useful to get everything back in sync if they aren’t.

[xaviml]

Hi guys,

I reviewed @sreknob's PR and the problem with the toggle_hold action is that in all integrations it is always fired up after the toggle action, so whatever we do in the toggle hold action, it will first toggle the light and that is rather not convenient/confusing. You can always give the functionality with custom controllers.

Thanks for the PR and the debug hunting, I would have never guessed it was the firmware. I will merge the PR after the request changes.

[sreknob]

@xaviml - glad to help out.
I was aware that a hold always fires a toggle event first with this remote. I do have one set up directly bound to bulbs at work and I find that it is useful for when lights go out of sync.
3.5 seconds for an effect is indeed a super long hold, and that's why I don't think users will get confused by it. It always does what is expected (ie, toggle) when you push it, and then if you want to get all the lights back into sync (has occasionally happened to me where my switch loses sync from my bulbs) and then a VERY long hold gets everything to back on full and default colour temp. This is the default behaviour with this remote. It's a fairly intentional process and I bet most users of this remote have never even tried it/figured out this is the default behaviour.
The bigger issue is that not all the integrations get a release/stop message so it can really only be used to fire a single event, like on_full_brightness.
Anyway, please reconsider. If you still think it should be removed, I'll drop it from the PR.

Any thoughts about having a default colour temp/xy_color default that is configurable?

[htvekov]

My two cents...

As the pause is EXTREMELY long until hold event is fired , I agree with @sreknob that a default color temp reset could be a useful addition of events for an E1810. Wasn't even aware that this was a default implementation of hold on IKEA hub 🤔😁

But should only be implemented when toggle is held from off position. Otherwise, from on position, lights would first turn off and after 3 seconds turn on again reset to default colours.

[xaviml]

Hi @sreknob,

Thanks for the detailed explanation. I understand now. So the default behaviour is already this? So if the light is on and you hold, it will turn the light off and if you wait 3 seconds, it will turn the light in full brightness and default temp?

I am not sure what you mean with "default colour temp/xy_color". Do you mean a default defined by user or hardcoded? If it's defined by user, you can already do that with custom controllers. I will accept your PR as it is. However, I have to options:

• Add a custom function to the controller to control the toogle_hold action. So if the light is off it will turn on the light and then it will put the light to full brightness and white colour otherwise or default color_temp (50%), but if the light is on and you hold, it will turn off and it will not turn back on. This is what @htvekov is mentioning.
• Leave as it is, so it will always turn to full brightness when holding.

Let me guys know what you think. Thank you :)

[htvekov]

Hi' Xavi/Blake.

As the wait is so extremely long for hold to be fired, I don't think any user would experience problems in daily use with either of the options.
If you wan't to reset colour/temp to default settings, then anyone would hardly find it directly annoying if lights first went off and came back on with full brightness and colors/temp reset.

But my personal opinion is that I would prefér function was only called from lights off 😉

Either way, it's yet another usefull addition to ControllerX. Which rapidly has gone from 'basic light controller' to one of the most versatile and helpful additions build for HA 🚀🚀😎👍

[sreknob]

Hey Guys -

Thanks for the additional discussion!

So yes, the default behaviour of the controller is kind of strange, It doesn't care what the state of the light is before the hold. If the lights are on, it tuns them off at the start of the hold, just the standard toggle command. Then after the long hold, it turns all the lights on to full brightness and 2700K color temp (for color and tunable bulbs).

I'm pretty sure the reason that it was designed this way is that these issues commands to an entire zigbee group. When you have no other way of controlling the lights and some get out of sync, then you could be left with bulbs of different color temps and no number of "steps" will get them back where you want them.

This way, the long press first toggles everything like standard (and yes, sometimes you do stand there in the dark for a few seconds) then everything comes back on at full brightness and 2700K/warm white. From there, you can then adjust as needed. You can see the ikea video about it here to illustrate what I'm talking about. What they don't have shown is that it also fixes the brightness out of sync as well (guess there were too many combinations to make videos about them all!) It's from their support section of their website.

I think it should do the default implementation and not get too fancy. Again, the use case is kind of limited by the nature of timing. It's pretty unlikely that the lights get out of sync but it's a great solution when they do. (I've never had it happen at home - just my 6 lights at my office which are just directly paired).

[xaviml]

Perfect, I will add it no matter if the light is on or off. It will be a nice feature to have to leave the light to a default setting, you are right. However, the way ControllerX is done, it syncs every time you long-press or press, because it takes the values from the first light of the group and changes the attributes according to that light, this is why you may not have experienced a desynchronization. I will create this and let you know once it is done to test.

Thank you for everything :)

[sreknob]

it takes the values from the first light of the group and changes the attributes according to that light,

I did not know this -- this is so cool!

Thanks @xaviml - you're the best! 💯

[htvekov]

Hi' Xavi.

That could be the reason my Hue light groups behaves irregular using ControllerX dimming up/down then ? 🤔

Lights don't follow each other exactly when dimming. And hold button only dims partly up/down and then stops.

If I create a manual light group in HA, dimming behaviour is perfect (understandable when I now know why 😊). Only on/off is not exactly syncronized - expected with separate calls for each entity.
But on/off can easily be mapped to a secondary controller that only handles toggle button via Hue light group and leave the dimming/colorshift part to primary controller using identical manual HA group.
A bit awkvard - but it should work nicely I expect.

And it's impossible for users with lights on Hue bridge and sensors on z2m to create and use z2m 'special' groups, as the lights are not exposed to z2m.

Does the code distinguish between a single entity and Hue light groups (checks is_hue_group: true ) or are they treated equal in code ? As domain for Hue groups in HA are identical to entities, it's the only way to tell if it's a single entity or group your dealing with.

[xaviml]

Hi guys,

I just released v2.4.0b1 with the changes that @sreknob added, plus a new predefined light action called sync that puts the light(s) to full brightness and 2700K color temperature or white color, depending on the supported color_mode for the light.

I tested it with E1810 controller with z2m integration and it does what is expected, like the video you sent.

You guys can let me know if it also works for deCONZ and ZHA.

[xaviml]

Hi @htvekov ,

Regarding your issue, ControllerX does not support Light Group, although depending on the setup it will work. The safest way to set up a group of lights is with Group, this way ControllerX knows is a group of lights and follows the attributes from the first light on the group (the master light).

This is how the group of lights are treated on ControllerX for the moment, so I cover all the cases since it relies on HA services. I do not intend to change this for specific devices.

This means that if you use light.gang it will be treated as 1 light for ControllerX, so it will depend on how HA treats the group of lights when calling the services homeassistant.turn_on/off with that light. If you want sync all the lights with ControllerX the best way is to create a group of lights.

[sreknob]

Awesome Xavi - will test tonight when I get home!

[htvekov]

Hi' Xavi.

Just tested the new hold function in beta v2.4.0b1 on an Ikea color bulb.
Can't test, as my bulb apparently doesn't support xy color/color temp settings ?
It's a Trådfri E27 CWS opal 600lm bulb.

2020-03-03 17:34:46.875043 WARNING office_controller: ------------------------------------------------------------
2020-03-03 17:34:46.876759 WARNING office_controller: Unexpected error in worker for App office_controller:
2020-03-03 17:34:46.878907 WARNING office_controller: Worker Ags: {'id': '113d35c1b1ae4c3d8a595544d71c3c89', 'name': 'office_controller', 'objectid': '76f1fdc3759e4729a8446bcfc631e88f', 'type': 'state', 'function': <bound method StateIntegration.callback of <core.integration.z2m.Z2MIntegration object at 0x74d02f28>>, 'attribute': 'state', 'entity': 'sensor.0x90fd9ffffe17d796_action', 'new_state': 'toggle_hold', 'old_state': '', 'pin_app': True, 'pin_thread': 0, 'kwargs': {'__thread_id': 'MainThread'}}
2020-03-03 17:34:46.880694 WARNING office_controller: ------------------------------------------------------------
2020-03-03 17:34:46.883281 WARNING office_controller: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/appdaemon/threading.py", line 709, in async_worker
await funcref(entity, attr, old_state, new_state, self.AD.state.sanitize_state_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/controllerx/core/integration/state.py", line 15, in callback
await self.controller.handle_action(new)
File "/config/appdaemon/apps/controllerx/core/controller.py", line 120, in handle_action
await action(*args)
File "/config/appdaemon/apps/controllerx/core/controller.py", line 28, in _action_impl
await method(self, *args, **kwargs)
File "/config/appdaemon/apps/controllerx/core/type/light_controller.py", line 292, in sync
color_attribute = await self.get_attribute(LightController.ATTRIBUTE_COLOR)
File "/config/appdaemon/apps/controllerx/core/type/light_controller.py", line 312, in get_attribute
raise ValueError(
ValueError: This light does not support xy_color or color_temp
2020-03-03 17:34:46.886182 WARNING office_controller: ------------------------------------------------------------

[xaviml]

I see, I will fix that up! @htvekov

[xaviml]

Okay, v2.4.0b2 released, you can check again. If color_temp and xy_color are not supported, then it just applies the changes to the brightness.

[htvekov]

Just tested to set xs and xy color directly from HA.
It's works flawlessly ??

But color_temp can't be set on this bulb from HA

[htvekov]

Ok, Xavi.

Tested v2.40b2

• Doesn't reset from on only from off.
• Does reset color temp but not brigtness to 100%

Still throws an error after hold

2020-03-03 19:13:10.153509 WARNING office_controller: ------------------------------------------------------------
2020-03-03 19:13:10.156264 WARNING office_controller: Unexpected error in worker for App office_controller:
2020-03-03 19:13:10.159204 WARNING office_controller: Worker Ags: {'id': '9babb452db0546d9a04a69658d1c15a8', 'name': 'office_controller', 'objectid': '42ed3c3cf60e418580cac0fe39d7e475', 'type': 'state', 'function': <bound method StateIntegration.callback of <core.integration.z2m.Z2MIntegration object at 0x74b14478>>, 'attribute': 'state', 'entity': 'sensor.0x90fd9ffffe17d796_action', 'new_state': 'toggle_hold', 'old_state': '', 'pin_app': True, 'pin_thread': 0, 'kwargs': {'__thread_id': 'MainThread'}}
2020-03-03 19:13:10.161847 WARNING office_controller: ------------------------------------------------------------
2020-03-03 19:13:10.165122 WARNING office_controller: Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/appdaemon/threading.py", line 709, in async_worker
await funcref(entity, attr, old_state, new_state, self.AD.state.sanitize_state_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/controllerx/core/integration/state.py", line 15, in callback
await self.controller.handle_action(new)
File "/config/appdaemon/apps/controllerx/core/controller.py", line 120, in handle_action
await action(*args)
File "/config/appdaemon/apps/controllerx/core/controller.py", line 28, in _action_impl
await method(self, *args, **kwargs)
File "/config/appdaemon/apps/controllerx/core/type/light_controller.py", line 292, in sync
color_attribute = await self.get_attribute(LightController.ATTRIBUTE_COLOR)
File "/config/appdaemon/apps/controllerx/core/type/light_controller.py", line 312, in get_attribute
raise ValueError(
ValueError: This light does not support xy_color or color_temp
2020-03-03 19:13:10.169616 WARNING office_controller: ------------------------------------------------------------

[htvekov]

@sreknob & @xaviml
Had a quick test with transition: 0 for toggle_hold on Ikea bulb.

From on position: Still only sets brightness to 100% but color remains unchanged
From off position: Brightness sets at 100% AND color is reset to 'whatever' white (2700K ?)

So with transition: 0 it works from off position for Ikea color bulb (on Hue bridge)

[htvekov]

@branitelj91

The transition issue we discuss in this thread, is only a problem with a specific ControllerX feature in beta test.

In general, there are issues with simultaneous brightness/color commands on Ikea bulbs, but nothing that will prevent any ControllerX configuration to work.

[branitelj91]

@branitelj91

The transition issue we discuss in this thread, is only a problem with a specific ControllerX feature in beta test.

In general, there are issues with simultaneous brightness/color commands on Ikea bulbs, but nothing that will prevent any ControllerX configuration to work.

well, for some reason, (i trust is missconfig), mine is not working no matter what change I make.
Confusing to some degree ;(

[sreknob]

@branitelj91 - indeed likely a configuration issue.
Post your config and appdaemon logs to the HA thread for ControllerX for more help. This way, when you do get it solved, others can benefit from it too (and we can keep the discussion on-topic here).

[xaviml]

Hi @branitelj91
Please open a new issue of type question. Please fill the body of the question with everything that is asked (AppDaemon logs, versions, integration, apps.yaml, etc.). The more information you give us, the better we will be able to help you :) Thanks!

[xaviml]

Ikea bulbs WILL accept both color/color temp AND brightness in same call, but ONLY with transition time: 0
When bulbs are busy 'transitioning' they apparently dont accept new commands until transitioning to new state is finished.

Interestingly enough, I knew this, but I forgot about it. I know you guys tried with transition 0, but I will remove the transition attribute from the request when calling from sync to see if that fixes it.

[xaviml]

I just released v2.4.0b3. I removed the transition attribute when sync action is called. Working well on my end, doing it from off and on. Let me know if it works as expected now.

Remember to click REINSTALL button in HACS 99 times before restaring AppDaemon server 🤣

Thank you guys!

[xaviml]

Also, @jrbenito could you confirm that your bug has disappeared and the controller works as before after the changes that @sreknob did? Thank you!

[htvekov]

Hi' Xavi

Just tested latest beta.

Same setup as previous:
Ikea colour bulb on Hue bridge and transition removed from app settings.

toggle_hold from on: Full brightness but no reset of color
toggle_hold from off: Unchanged brightness on bulb (but HA state for brightness = 100%) and color is reset to 2700K

Just tested an additional bulb as well.
An Ikea white spectrum E27 bulb displays exact same behaviour via Hue bridge.

And finally a Philips Hue White And Color Ambiance E27 bulb.
toggle_hold from on: Full brightness but NO reset of color either on Hue bulb ?
toggle_hold from off: Everything works !! 😊

[jrbenito]

Also, @jrbenito could you confirm that your bug has disappeared and the controller works as before after the changes that @sreknob did? Thank you!

Hi @xaviml ,

I will try my best to confirm today night. Sorry for delay, I am having busy days at work this week. Today will be! (btw, here is 9AM, so in about 12 hours I come back with an answer :D)

[htvekov]

Hi' again, Xavi.

Just tested direct service calls from HA
Tested both hs_color, xy_color and rgb_color as parameter.
Instant change on both brightness and color in all HA service call tests !

But if I DON'T state the transition: 0 parameter, then color will change but brightness will NOT change !!! Sometimes i can trigger brightness change after several repeated identical calls.

And changes to color/brightness are NOT without transition ? Looks like transition 300-400ms to me. But transition attribute shouldn't be added by the Hue bridge, as it doesn't support transition settings for other bulbs than their own. Assume that the Ikea bulbs have a 'default' transition period if not otherwise stated in calls ? Can someone with Ikea bulbs on z2m network confirm this, please ?

Conclusion: Transition attribute (with 0 value) can't be omitted, but HAS to be included in call !

Really, really strange that Ikea hasn't fixed this obvious bug in their zigbee fw ??
Unless, their hub/bridge handles scenes/transitions in a different way ?
Anyway, fw can't be completely ZLL compliant ? Hopefully Zigbee 3.0 will fix all that in near future.

OK. Extensive 'test night' 😉🌚⭐
Moved my Ikea color bulb from my Hue Bridge to my z2m network.
Service calls from HA with transition omitted now results in instant change (no transition, if not specified as parameter)
Conclusion: Hue bridge adds some 'Hue default' transition period to zigbee commands, if transition: 0 is not explicitly specified (lovely!! 🙄😫)

With Ikea bulb on z2m network, latest beta toggle_hold works correctly from off position.
But from on position still only brightness is set to 100% - not the color.

One final note. With Ikea bulb now on z2m network, I can confirm that bulb indeed accepts both brightness AND color change in same call. But implementation of transition is somewhat 'left hand' work. If both brightness AND color is in call, then brightness change is instant and only color transitions !?!? If only brightness OR color is in call, then both can do transition.

Conclusion: Ikea bulbs can apparently only handle one transition at a time and color transition has highest priority !

Pheeww ! 😅😊
Some test results for you to work with, Xavi 😁🍻

Ciao !

[htvekov]

While I have the bulb on the z2m network, I took advantage of the newly introduced OTA update function of Ikea bulbs via zigbee2mqtt.

I updated from fw 1.3.002 to fw 1.3.009 on my Ikea color bulb.
Can't see any changes though, in behaviour regarding this specific issue or in general.

This Ikea bulb issue with both bulb fw bug- and the Hue bridge issues is not easy to navigate in...

Night everyone and a pleasant EVENING to you @jrbenito 😉😁

zigbee2mqtt:info 2020-03-05 21:57:40: Finished update of '0x90fd9ffffe838cb3', from '{"softwareBuildID":"1.3.002","dateCode":"20170315"}' to '{"softwareBuildID":"1.3.009","dateCode":"20180410"}' zigbee2mqtt:info 2020-03-05 21:57:40: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"type":"ota_update","message":"Finished update of '0x90fd9ffffe838cb3', from '{\"softwareBuildID\":\"1.3.002\",\"dateCode\":\"20170315\"}' to '{\"softwareBuildID\":\"1.3.009\",\"dateCode\":\"20180410\"}'","meta":{"status":"update_succeeded","device":"0x90fd9ffffe838cb3","from":{"softwareBuildID":"1.3.002","dateCode":"20170315"},"to":{"softwareBuildID":"1.3.009","dateCode":"20180410"}}}'

[jrbenito]

@xaviml,

All good now!!!! thanks for continuous support!

@ALL

Great team effort here, amazing results!

[jrbenito]

Organizing:

My E1810 controller now can:

• Toggle lights
• Dim/Bright lighs
• Change color temperature
• Reset lights to defaults by toggle long press
• Dim/Brigh by long press
• Change color temperature by long press

Thanks guys, WAF is now reestablished and you saved my day.

cheers

[xaviml]

Conclusion: Transition attribute (with 0 value) can't be omitted, but HAS to be included in call !

Hi @htvekov. Sorry, but are you saying that if transition is added with 0, it works as expected? So from on will put the light full brightness and color in 2700K and the same from off?

All good now!!!! thanks for continuous support!

Perfect, thank you @jrbenito !!

[htvekov]

Hi' Xavi.

I'll try to recap from memory (I'm at work 😁)
Above conclusion was based on results from direct HA service calls with bulb on Hue bridge.

I only tested latest beta without any transition settings in config.

With Ikea colour bulb on z2m and transition removed from app settings:

With Ikea bulb on z2m network, latest beta toggle_hold works correctly from off position.
But from on position still only brightness is set to 100% - not the color.

With Ikea colour bulb on Hue bridge and transition removed from app settings.:

toggle_hold from on: Full brightness but no reset of color
toggle_hold from off: Unchanged brightness on bulb (but HA state for brightness = 100%) and color is reset to 2700K

So there's issues with toggle_hold from on position on both Hue bridge and z2m network.
Color will not reset correctly. Not even on a Hue bulb on Hue bridge.

I'll expect it to work on Hue bridge if you send transition: 0 as attribute with the call instead of omitting it.

But I really can't figure out why beta doesn't work correctly from on position when bulb is on z2m network ? HA service calls works flawlessly with bulb on z2m network - with transition attribute or omitted completely.

Is the above explanation understandable at all, Xavi ?? 🤔🙄

[htvekov]

Hi' Xavi.

Just repeated the tests on both Hue bridge and z2m network with transition: 0 added to app config.

Same results as earlier test. No difference at all.

Ciao !

[htvekov]

Hi' Xavi.

Latest beta v2.4.0b3 z2m logs.
Ikea color bulb on z2m network and transition: 0 attribute set in app (this is omitted though by current ControllerX beta)

Z2m log of toggle_hold event from off. All data is correct in mqtt set command, and both brightness and color command are in log.

zigbee2mqtt:info  2020-03-07 20:50:58: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":94,"battery":16,"update_available":true,"action":"toggle_hold"}'
zigbee2mqtt:info  2020-03-07 20:50:58: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":94,"battery":16,"update_available":true,"action":""}'
zigbee2mqtt:debug 2020-03-07 20:50:59: Received MQTT message on 'zigbee2mqtt/0x90fd9ffffe838cb3/set' with data '{"state": "ON", "color": {"x": 0.324, "y": 0.329}, "brightness": 255}'
zigbee2mqtt:debug 2020-03-07 20:50:59: Publishing 'set' 'brightness' to '0x90fd9ffffe838cb3'
zigbee2mqtt:info  2020-03-07 20:50:59: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe838cb3', payload '{"state":"ON","color":{"x":0.301,"y":0.116},"brightness":255,"update_available":false}'
zigbee2mqtt:debug 2020-03-07 20:50:59: Publishing 'set' 'color' to '0x90fd9ffffe838cb3'
zigbee2mqtt:info  2020-03-07 20:50:59: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe838cb3', payload '{"state":"ON","color":{"x":0.324,"y":0.329},"brightness":255,"update_available":false}'

Z2m log of toggle_hold event from on. All data is still correct in mqtt set command, but only brightness command is in log.

zigbee2mqtt:info  2020-03-07 20:23:26: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":94,"battery":16,"update_available":true,"action":"toggle_hold"}'
zigbee2mqtt:info  2020-03-07 20:23:26: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":94,"battery":16,"update_available":true,"action":""}'
zigbee2mqtt:debug 2020-03-07 20:23:26: Received MQTT message on 'zigbee2mqtt/0x90fd9ffffe838cb3/set' with data '{"state": "ON", "color": {"x": 0.324, "y": 0.329}, "brightness": 255}'
zigbee2mqtt:debug 2020-03-07 20:23:26: Publishing 'set' 'brightness' to '0x90fd9ffffe838cb3'
zigbee2mqtt:info  2020-03-07 20:23:26: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe838cb3', payload '{"state":"ON","color":{"x":0.137,"y":0.041},"brightness":255,"update_available":false}' 

The set color command is never fired.

I belive that transition: 0 attribute is needed for Ikea bulb to function with toggle_hold from both on and off and with bulb on both Hue bridge and z2m network.

in betav2.4.0b2 transition is included in call (defaults to 0,3 sec. i believe) and default can be changed via app settings. Here the Ikea bulb gets all three calls:

zigbee2mqtt:info  2020-03-07 21:23:40: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":89,"battery":16,"update_available":true,"action":"toggle_hold"}'
zigbee2mqtt:info  2020-03-07 21:23:40: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe17d796', payload '{"linkquality":89,"battery":16,"update_available":true,"action":""}'
zigbee2mqtt:debug 2020-03-07 21:23:40: Received MQTT message on 'zigbee2mqtt/0x90fd9ffffe838cb3/set' with data '{"state": "ON", "color": {"x": 0.324, "y": 0.329}, "transition": 0.0, "brightness": 255}'
zigbee2mqtt:debug 2020-03-07 21:23:40: Publishing 'set' 'brightness' to '0x90fd9ffffe838cb3'
zigbee2mqtt:info  2020-03-07 21:23:40: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe838cb3', payload '{"state":"ON","color":{"x":0.528,"y":0.446},"brightness":255,"update_available":false}'
zigbee2mqtt:debug 2020-03-07 21:23:40: Publishing 'set' 'color' to '0x90fd9ffffe838cb3'
zigbee2mqtt:info  2020-03-07 21:23:40: MQTT publish: topic 'zigbee2mqtt/0x90fd9ffffe838cb3', payload '{"state":"ON","color":{"x":0.324,"y":0.329},"brightness":255,"update_available":false}'
zigbee2mqtt:debug 2020-03-07 21:23:40: Publishing 'set' 'transition' to '0x90fd9ffffe838cb3'

Ciao !

[sreknob]

I just tried this out with a few other scenarios using the current beta, including an osram bulb on zha and a hue bulb on hue hub. No app setting of transition. The behaviour is the same. Sync works when called with the bulb in an ON state but does not work when called with the bulb in the OFF state. This turns the bulb on to full brightness with the color unchanged.

calls from HA, regardless of the state of the bulb work:
light.turn_on

entity_id: light.osram_test_bulb
brightness: '254'
xy_color: [0.323, 0.329]

[xaviml]

Hi all, I have been debugging but I did not seem to find a solution that works well when the light is on and off and also for color temperature and xy color. For this reason, I will keep the sync function in case this gets solved in the future from the third parties, but it will just put the brightness into the maximum level.

I have tried to change the homeassistant/turn_on service to light/turn_on service and the problem still persisted in my end with a color bulb. I also tried sending transition: 0 and no transition and the problem was still there. If someone finds a solution that satisfies all condition, I will be glad to add it. However, for the moment sync functionality will impact the brightness only.

Thank you all for testing this out and help me to find a solution to this!

[htvekov]

Hi' Xavi.

I don't know if it's possible at all, to find a solution that covers all bulb types on all zigbee integration solutions ?

Anyway, just wanted to share my 'workaround' solution.
This might works for some out there, if they can't live without sync function from on position 😁😊

Using latest beta v2.4.0b3 I've made some controllerX apps to 'emulate' toggle_hold from off when light is actually on 😁
It's completely 'quick and dirty' for test purposes, but it works with toggle_hold both from on and off light positions.
I just test if toggle_hold originally came from an light on position. If yes, turn on light again and call toggle_hold via mqtt

Tested:

• Ikea color bulb on z2m network
• Hue bulb on Hue bridge
• Not tested yet is Ikea bulb on Hue bridge (bulbs are in bedrooms where family members are sleeping now 😴)

hallway_light_group_no_toggle:
  # all actions, but toggle_hold
  module: controllerx
  class: E1810Controller
  controller: sensor.0x90fd9ffffe17d796_action
  integration: z2m
  smooth_power_on: true
  light: light.0x90fd9ffffe838cb3_light
  actions:
    - arrow_left_hold
    - arrow_left_release
    - arrow_right_hold
    - arrow_right_release
    - arrow_right_click
    - arrow_left_click
    - brightness_up_click
    - brightness_down_click
    - brightness_up_release
    - brightness_down_release
    - brightness_up_hold
    - brightness_down_hold
    - toggle

hallway_light_group_toggle_hold_from_off:
  module: controllerx
  class: E1810Controller
  controller: sensor.0x90fd9ffffe17d796_action
  integration: z2m
  light: light.0x90fd9ffffe838cb3_light
  actions:
    - toggle_hold
  constrain_input_boolean: light.0x90fd9ffffe838cb3_light,on #ensure that toggle_hold will only be called when lights was off and has just turned on (toggle_hold from off)

hallway_light_group_toggle_hold_from_on:
  module: controllerx
  class: CallServiceController
  controller: sensor.0x90fd9ffffe17d796_action
  integration: z2m
  mapping:
    toggle_hold:
      - service: light.turn_on
        data:
          entity_id: light.0x90fd9ffffe838cb3_light
          brightness: 255
          transition: 0
      - service: mqtt.publish #publish the toggle_hold command again, now with lights on
        data:
          topic: 'zigbee2mqtt/Ikea hallway'
          payload: '{"linkquality":80,"battery":80,"update_available":true,"action":"toggle_hold"}'
      - service: mqtt.publish
        data:
          topic: 'zigbee2mqtt/Ikea hallway'
          payload: '{"linkquality":80,"battery":80,"update_available":true,"action":""}'
  constrain_input_boolean: light.0x90fd9ffffe838cb3_light,off #ensure that toggle_hold will only be called when lights was on and was turned off by first toggle (toggle_hold from on) 

Thanks for all your hard work, Xavi ! 👍👍😎

[htvekov]

@sreknob

Did I understand correctly, when you say that sync (both color and brightness) works, with beta v2.4.0b3, when toggle_hold is called from lights originally in on position ?
Then I have the exact opposite problem (Ikea/Hue bulbs on z2m and Hue bridge), as toggle_hold only works (color set) when light are originally off.

Really strange then...

[xaviml]

Wow! That is an extensive example of how to configure ControllerX in advance mode. I have to say you control better the ControllerX configuration than me 🤣

However, from now on sync will only change brightness, so you might have to change that a little bit. If you need any help in the configuration or you change the configuration so it works well, let me know and I will post it or maybe even try to fix this.

Thank you @htvekov :)

[xaviml]

I also created a bug for the sync problem, so I can close this issue (#54)

[sreknob]

thanks @xaviml
@htvekov - also, impressive config! I was just calling sync, (without the toggle first) via a custom controller instead of the E1810 centre button. We're likely talking about the same thing as you toggled first to switch to the opposite direction of what I had. Let me know if this doesn't make sense...

[htvekov]

Hi' Xavi

I'll comment in issue #54 :-)

[htvekov]

@sreknob

You 'cheated' then, omitting the first toggle 😉😁
Then I would expect that Osram bulbs via ZHA would work as well with my suggestion to code change for next beta in issue #54 😎