Magic Areas 3.0.0 - Beta - Issue Tracker

[jseidl]

This is an issue thread to track bugs within the 3.0.0 release.

Please NO FEATURE REQUESTS HERE, ONLY BUGS. Please cut a fresh ticket for feature requests

THIS IS A BREAKING RELEASE, READ THE WIKI FOR INFORMATION ON CONCEPTS AND CONFIGURATION!

Release download: https://github.com/jseidl/hass-magic_areas/releases/tag/3.0.0-beta Wiki/Documentation: https://github.com/jseidl/hass-magic_areas/wiki

[jseidl]

Hello contributors and volunteers! This is a call for beta-testers!

This is a breaking change so you will have to reconfigure the integration. I understand if you chose not to but appreciate if you do and report! (do report documentation gaps as well)

cc: @cerebrate @KTibow @sti0 @caphm @Bodge-IT @sjthespian @TheArcturian @danielbrunt57

[cerebrate]

Count me in, certainly! I love a good beta.

(Also, for anyone else doing this who doesn't already know, .storage/core.config_entries is the file you want to copy your existing configuration out of if it's complex and clicking around taking notes lacks appeal. 😄 )

[cerebrate]

Got one, and it's quite the issue:

I use light groups principally to create the groiups, and not to control the lights. (Reasons: I have adaptive_lighting set up for most of my room lights, and my presence detection isn't yet reliable enough; once the latter changes, I'm going to start using it more fully, but that is not this day.)

So, for example, if I copy my bathroom config, it looks like this:

              {
                  "entry_id": "8555194b441ace28b1dc3c524aeb071e",
                  "version": 1,
                  "domain": "magic_areas",
                  "title": "Bathroom",
                  "data": {
                      "on_states": [
                          "on",
                          "home",
                          "playing",
                          "open"
                      ],
                      "sleep_lights": [],
                      "presence_sensor_device_class": [
                          "motion",
                          "occupancy",
                          "presence"
                      ],
                      "update_interval": 60,
                      "notification_devices": [],
                      "aggregates_min_entities": 2,
                      "exclude_entities": [],
                      "clear_timeout": 60,
                      "notify_on_sleep": false,
                      "main_lights": [],
                      "include_entities": [],
                      "type": "interior",
                      "sleep_state": "on",
                      "features": [],
                      "icon": "mdi:texture-box",
                      "night_state": "on",
                      "sleep_timeout": 0,
                      "name": "Bathroom",
                      "id": "bathroom"
                  },
                  "options": {
                      "type": "interior",
                      "include_entities": [],
                      "exclude_entities": [],
                      "presence_device_platforms": [
                          "media_player",
                          "binary_sensor"
                      ],
                      "presence_sensor_device_class": [
                          "motion",
                          "occupancy",
                          "presence"
                      ],
                      "on_states": [
                          "on",
                          "home",
                          "playing",
                          "open"
                      ],
                      "clear_timeout": 60,
                      "update_interval": 60,
                      "icon": "mdi:toilet",
                      "features": {
                          "media_player_groups": {},
                          "health": {},
                          "area_aware_media_player": {
                              "notification_devices": [],
                              "notification_states": [
                                  "extended",
                                  "occupied"
                              ]
                          },
                          "aggregates": {
                              "aggregates_min_entities": 1
                          },
                          "presence_hold": {
                              "presence_hold_timeout": 0
                          },
                          "light_groups": {
                              "overhead_lights": [
                                  "light.bathroom_light_center",
                                  "light.bathroom_light_left",
                                  "light.bathroom_light_right"
                              ],
                              "overhead_lights_states": [],
                              "overhead_lights_act_on": [],
                              "sleep_lights": [],
                              "sleep_lights_states": [],
                              "sleep_lights_act_on": [],
                              "accent_lights": [],
                              "accent_lights_states": [],
                              "accent_lights_act_on": [],
                              "task_lights": [],
                              "task_lights_states": [],
                              "task_lights_act_on": []
                          }
                      },
                      "secondary_states": {
                          "accent_entity": "",
                          "accent_state": "on",
                          "extended_time": 120,
                          "extended_timeout": 300,
                          "sleep_timeout": 60,
                          "sleep_state": "off",
                          "sleep_entity": "input_boolean.day_mode",
                          "dark_state": "on",
                          "dark_entity": ""
                      }
                  },
                  "pref_disable_new_entities": false,
                  "pref_disable_polling": false,
                  "source": "user",
                  "unique_id": "Bathroom",
                  "disabled_by": null
              },

...in which as you can see, I'm using none of the options to control the lights and so - I would think - nothing of the sort would happen.

Except I can't get the lights in there to turn off . If I turn them off, they come back on in a matter of seconds. The same goes for another area, and I also have one, with similar all-disabled light control options, in which the lights turn off occasionally by themselves for no readily explicable reason.

[jseidl]

This is very weird. Will replicate this setup in by testbed and try to replicate. If you have no states defined it should not act on it. Maybe it's the global group, will take a look. Thanks for reporting!

[jseidl]

Meanwhile while I work on the patch try excluding the lights from the area. Sorry about that!

[jseidl]

I think I've found the culprit. Definitely is the global area light group ("$area_lights").

Normal secondary groups have the following snippet which would prevent that

        # Do not handle lights that are not tied to a state
        if not self.assigned_states:
            _LOGGER.debug(f"{self.name}: No assigned states. Noop.")
            return False

But the global area light group doesn't. Will fix this in the next mins.

[jseidl]

Can you try changing line 194 on light.py from

# If we don't, just turn on all of them
return self._turn_on()

to

if AREA_STATE_OCCUPIED in new_states:
        # If we don't, just turn on all of them
        return self._turn_on()

And see if that solves the issue. Pushed the fix for branch release/3.0.0-beta, if you use code directly from it, it will be fixed. The beta release would not be updated tho (would need to make a new release)

[cerebrate]

Thanks! That looks to have worked, certainly for the cannot-turn-light-off issue.

(I don't have a reliable way to provoke the occasionally-turning-off-uncommanded one, so I'll just have to wait and see if it happens again.)

[cerebrate]

No sign yet of that issue recurring, which I shall take as a good sign.

On the documentation-gaps front, and thinking about light groups, I think it might be useful to have some more information regarding how the settings relating the light-groups to the states work.

I think I understand the distinction for "When should overhead lights be controlled?", with occupancy being the main room-occupied sensor and state meaning according to the secondary states selected under "states which overhead lights should be turned on", but then I see that both "occupied" and "extended" are available under those states, so then I find myself wondering what the difference is, if any, between selecting "occupancy" in the former vis-a-vis "state" and "occupied". I'm also wondering how these interact: if I select more than one of "occupied", "extended", or "sleep" when choosing states for lights to be turned on, does that require all of them to be true, or any of them to be true? And if I pick "occupied", does that exclude extended - i.e., should I pick both to make the lights come on when the room is occupied and stay on, or would just occupied to even if the room later becomes extended?

This could mostly be solved by experiment reasonably straightforwardly, I suspect, but there are enough possibilities here that some extended explanation for the newbie and/or some examples of use would probably go a long way.

[cerebrate]

Also, I note that when picking states for lights to be on in, I can only see occupied, extended, and sleep, not the accented or dark secondary states mentioned on the wiki?

[cerebrate]

Okay, the lights-turning-off one is still happening, but I have a better profile of it now.

It looks as though even without any configuration (as per file above, in that respect; this is happening in every room with a presence sensor) to tell magic_areas to operate the lights according to occupancy, it still is doing so. The lights go out when presence is first detected (at which point they're already on, so no change) and then clears, at which point they go off.

Should presence again be detected, the lights do turn on again.

Also, interestingly, this is affecting all lights in the area, not just those mentioned in the configuration; in my office, this switches off and on the LED strip I use for my 3D printer, which while in the "Office" area in Home Assistant, isn't included as a light in the light_groups configuration for magic_areas. (And, indeed, isn't part of the light.office_lights or light.overhead_lights_office entities it creates.)

[jseidl]

Also, I note that when picking states for lights to be on in, I can only see occupied, extended, and sleep, not the accented or dark secondary states mentioned on the wiki?

Yeah that's true, dark shouldn't be there, will fix the documentation as dark is a required state apart from others, although accented should show. Will check.

It looks as though even without any configuration (as per file above, in that respect; this is happening in every room with a presence sensor) to tell magic_areas to operate the lights according to occupancy, it still is doing so. The lights go out when presence is first detected (at which point they're already on, so no change) and then clears, at which point they go off.

This is actually the default behavior if you don't specify any lights (it treats all of them instead). That might be the wrong way to default but it's just how it was coded in the first place. Will give some thought. If you don't want any control unfortunately you have to give up light groups functionality which is not ideal.

Also, interestingly, this is affecting all lights in the area

Yes, this is the same as above. Will work on solving that. Having a "default all" really forces you to use the control functionality. I guess I never ran into that because whenever I don't want the lights to turn on I "trick it" into thinking it's always bright with a mock sensor, but you have a good point.

[Bodge-IT]

Configuration popup without field labels https://drive.google.com/file/d/1ygMaP2MqJSg_0ZIzID_C-d4obfjg8qAM/view?usp=sharing This was first entry to config after restarting HA

Scratch this retesting...was an install issue

[cerebrate]

It looks as though even without any configuration (as per file above, in that respect; this is happening in every room with a presence sensor) to tell magic_areas to operate the lights according to occupancy, it still is doing so. The lights go out when presence is first detected (at which point they're already on, so no change) and then clears, at which point they go off.

This is actually the default behavior if you don't specify any lights (it treats all of them instead). That might be the wrong way to default but it's just how it was coded in the first place. Will give some thought. If you don't want any control unfortunately you have to give up light groups functionality which is not ideal.

I may have phrased this badly. The lights are specified, it's only the setting for when they should be controlled that is not (or rather, explicitly changed from the default of "occupancy" to unset). So for my office, the light-group config looks like this:

                        "light_groups": {
                            "overhead_lights": [
                                "light.office_ne_downlight",
                                "light.office_sw_downlight"
                            ],
                            "overhead_lights_states": [],
                            "overhead_lights_act_on": [],
                            "sleep_lights": [],
                            "sleep_lights_states": [],
                            "sleep_lights_act_on": [],
                            "accent_lights": [
                                "light.office_indicator_lamp"
                            ],
                            "accent_lights_states": [],
                            "accent_lights_act_on": [],
                            "task_lights": [],
                            "task_lights_states": [],
                            "task_lights_act_on": []
                        }

Hence my confusion, since in this area (in HA) there is also _light.3d_printer_lightstrip, which is specifically excluded from the magic_areas config above since it should be touched only by its own automations and not anything else. So that half of the issue looks as if I can't exclude a light from the light_group since despite specifying a list of overhead and accent lights, it's controlling all of them anyway?

A default-all for light groups (presumably just for one type of light) would make perfect sense to me, but this is happening when lights are being explicitly specified.

I'm not quite grasping the logic of the other half, too, because where controlling them is concerned, it seemed to me that removing "occupancy" from - and adding nothing to - _overhead_lights_acton should turn off that default and leave them on manual? And instead it seems to be the case that "occupancy" and unset have the same effect, and there isn't any way to turn off control?

Which again is a case of the default making sense to me, but not-respecting an explicit change from the default seems odd.

So all in all, I'm pretty sure I'm misunderstanding how this is supposed to work.

Yeah that's true, dark shouldn't be there, will fix the documentation as dark is a required state apart from others, although accented should show.

Hm. If you can't use dark there to control the light group behavior, what does it do? I can't find a suggestion of it controlling anything else in the docs.

[Bodge-IT]

Trying to configure my rooms after deleting most of them to reset, I get this https://drive.google.com/file/d/1yZ07SxhHledwpHuxDea-qwLaqH2m8PQz/view?usp=sharing

Not sure what the flow is referring to.

Update: OK, that error cleared and my config more or less back to norm.

[jseidl]

'm not quite grasping the logic of the other half, too, because where controlling them is concerned, it seemed to me that removing "occupancy" from - and adding nothing to - overhead_lights_act_on should turn off that default and leave them on manual? And instead it seems to be the case that "occupancy" and unset have the same effect, and there isn't any way to turn off control?

The thing is if any of the groups are listening to a state change, then the All group takes action with all the lights, effectively not letting you not use light control if you use light groups. That's prolly a poor assumption on my part so I need to figure out a way of letting users have the light groups without any control

Regarding exclusion, excluding on the area should exclude from everywhere but not defining on the light group categories won't stop it from showing up on the All light group.

Hm. If you can't use dark there to control the light group behavior, what does it do? I can't find a suggestion of it controlling anything else in the docs.

So dark is a pre-requisite for light control to work. If dark isn't present in the area, light control will not execute for turning ON lights (but will for turning off IIRC). If the area doesn't have a dark entity then light control will work assuming it's always dark. The states you can specify (occupied, extended and such) works on top of the room being on dark state.

[jseidl]

Trying to configure my rooms after deleting most of them to reset, I get this https://drive.google.com/file/d/1yZ07SxhHledwpHuxDea-qwLaqH2m8PQz/view?usp=sharing

Not sure what the flow is referring to.

This is weird, can you try deleting the offending area and restarting again? Also reload your integrations page before trying to configure again

[cerebrate]

The thing is if any of the groups are listening to a state change, then the All group takes action with all the lights, effectively not letting you not use light control if you use light groups. That's prolly a poor assumption on my part so I need to figure out a way of letting users have the light groups without any control

Thanks. I think I see how this (and dark) works, now.

[I also took a whack at the most naive solution, adding a boolean option to light groups that defaults to True, with the notion that it would simply no-op state_change_primary and state_change_secondary if toggled off, but I wasn't able to figure out enough about HA/Voluptuous validation in the time I've had spare to make that work.]

[jseidl]

Yeap, I'm also considering this. No worries I'll take a stab at it tonight. I'm thinking on adding a turn_on_state to the all group and a drop down between ("","occupied") which would do the same thing. If you select occupied you have control, if empty, no control. This would allow to grow to other states in the future (but it probably wont). Still churning which would be the better way to go around this. Thanks for the report!

[jseidl]

[I also took a whack at the most naive solution, adding a boolean option to light groups that defaults to True, with the notion that it would simply no-op state_change_primary and state_change_secondary if toggled off, but I wasn't able to figure out enough about HA/Voluptuous validation in the time I've had spare to make that work.]

I ended up going that route. Simpler. Check out the release branch, update has been tested on both test env and my prod env (house), works well but now you have to go back and reconfigure all areas because the default is False

I'll update the wiki for Light Groups as you've mentioned. Wiki updated!

[Bodge-IT]

I see for the Dark detector entity, you are expecting state which excludes light sensors until you create a binary sensor for it, correct?

[jseidl]

I see for the Dark detector entity, you are expecting state which excludes light sensors until you create a binary sensor for it, correct?

The dark entity whenever in dark state will add dark the area's secondary state. I just updated the wiki with some better explanation about dark: https://github.com/jseidl/hass-magic_areas/wiki/Light-Groups

I have a illuminance sensor (weatherstation_illuminance) outside and then a template binary sensor (weatherstation_light) which is on when illuminance is greater than 200 (YMMV) and off otherwise. Then I use this template sensor as my dark entity with dark state of off (meaning whenever this entity is off, then it's dark). Hope I've managed to explain it right

[Bodge-IT]

Yep, that's what I was thinking. Use binary sensor of illuminance sensor.

On Mon, 18 Oct 2021 at 09:46, Jan Seidl @.***> wrote:

I see for the Dark detector entity, you are expecting state which excludes light sensors until you create a binary sensor for it, correct?

The dark entity whenever in dark state will add dark the area's secondary state. I just updated the wiki with some better explanation about dark: https://github.com/jseidl/hass-magic_areas/wiki/Light-Groups

I have a illuminance sensor (weatherstation_illuminance) outside and then a template binary sensor (weatherstation_light) which is on when illuminance is greater than 200 (YMMV) and off otherwise. Then I use this template sensor as my dark entity with dark state of off (meaning whenever this entity is off, then it's dark). Hope I've managed to explain it right

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jseidl/hass-magic_areas/issues/144#issuecomment-945541220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOLMKRU5OF6UZSH6GLJ67TUHPNFHANCNFSM5GD5TT4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[cerebrate]

I ended up going that route. Simpler. Check out the release branch, update has been tested on both test env and my prod env (house), works well but now you have to go back and reconfigure all areas because the default is False

Been trying this out here this morning, and looks like everything's working great!

(Out of curiosity - if I understand the code correctly, turning off automatic control will leave all the magicareasarea* events firing as normal, yes? I have some ideas how I can use those to combine magic_areas goodness with my existing idiosyncratic lighting automation...)

[cerebrate]

Re dark :

I have an illuminance sensor in all my main rooms (a TSL2561 built into my general environment sensors), so added an input_number to define the exact meaning of "dark", and a bunch of template sensors of the form:

  template:
    - binary_sensor:
      - name: "Living Room Dark?"
        state: >-
          {{ states('sensor.area_illuminance_lx_living_room')|float(0.0) < states('input_number.darkness_threshold')|float }}
        icon: >-
          {% if is_state('binary_sensor.living_room_dark', 'on') %}
            mdi:brightness-1
          {% else %}
            mdi:brightness-7
          {% endif %}

...to feed magic_areas dark state and any other automation that needs to know. I haven't used them for much yet, but they seem to work pretty well so far.

[jseidl]

(Out of curiosity - if I understand the code correctly, turning off automatic control will leave all the magicareasarea* events firing as normal, yes? I have some ideas how I can use those to combine magic_areas goodness with my existing idiosyncratic lighting automation...)

Precisely. The automatic control check happens on the event listener side so the events are fired but ignored by the feature in that area

[andyinno]

Hi!

I just discovered the 3.0.0 beta. Currently just installed and reading the documentation.

First thing I am noticing... Some lights behave differently compared to what I am expecting.

I configured some accent light and some ceiling lights. When I enter, both are on. I was expecting only the ceiling lights to be on.

Did I misread the documentation?

[jseidl]

Hi @andyinno , the lights will light up according to what you set on their states. If they're on occupied they'll come up right away. See https://github.com/jseidl/hass-magic_areas/wiki/Light-Groups

[andyinno]

Hi

Yes. That's clear to me. But... I configured the dark state and I use one lamp only during sleep state.

Actually I see all the lamps on. I need to investigate on the reason, anyway I am not sure I understand correctly the wiki page table

The dark state behavior matrix, for example the second row:

If occupied and dark state goes to off, shouldn't the lights turn off instead of no-op?

[jseidl]

Yes. If you're getting noop check if you've enabled automatic control (the first checkbox) on the feature options page

[KTibow]

got your ping, i updated ha-blueprint so now the flake8 actually should work

[andyinno]

Ok. I got the reason why the lights don't turn off.

Basically in the configuration I misunderstood the state configuration that goes with the presence.

I was in the room for some time and therefore the room was in the extended state. The state parameter was maintaining the room occupate and it was basically in a deadlock.

State active and it could not exit because the state was active. Question, is this something intentional? It seems more a deadlock than a feature

[andyinno]

Update:

This is the current status. The room is marked active. No active sensors, the lights are on.

Or there is something that I do not understand from the doc, or it is not working correctly.

Any hint?

[andyinno]

Wait wait wait... Clear timeout... Is not in seconds right? It is not described in the row. But... All other settings are in seconds. Are they minutes? Hours? Days?

[jseidl]

Clear timeout... Is not in seconds right? Everything is in seconds BUT clear timeout changes once it enters the extended state (configurable).

Also check the State wiki https://github.com/jseidl/hass-magic_areas/wiki/Area-State

So whenever any of your presence sensors goes on, it sets the area to occupied (if not already) and it keeps there until clear_timeout. If any sensor triggers during that timeout wait, it resets the timeout again. The room will only go out of occupied state if there are no triggers from the presence sensor in clear_timeout seconds

[andyinno]

Thank you for your reply

I think something fights with the clear timeout setting.

Living room became active at 3:45 am. (my wife woke up for a couple of minutes) I woke up a couple of minutes ago and the lights in the living room was on.

My question related the extended is related to the fact that

-no motion in 3 hours

• area is still marked active
• extended timeout is marked at 600 seconds because it is generated by xiaomi sensors that basically sends the update every minute of so.

Also... I configured different lights to be turned on if sleep mode or normal mode.

This morning all the lights were on

[andyinno]

Update: I disabled the extended state by setting a really long detection time. Without the extended state the lights turns off.

I think something is not working correctly with the extended state, someone can confirm that it is working and clearing with the configured delay? The default time provided by the config is 60.is this also in seconds?

[jseidl]

Alright I think I see what's going on. I'm confident that that's a configuration issue. The feature is working 100% for everyone else so far.

So there are two things going on: 1) One (or more) of your sensors are not letting the room clear. You'd need to turn debug logging on for Magic Areas in order to see who keeps triggering presence update:

logger:
    default: warning
    logs:
        custom_components.magic_areas.binary_sensor: debug

2) You got the feature configuration wrong. There name of the light category doesn't relate to the state automatically. For example "Sleep lights" won't do nothing on "sleep state", unless you select "sleep" under "States which sleep lights should turn on". Currently you have "occupancy" state on all of them, meaning they will all come up at the same time when the area gets occupied. "When should XYZ lights be controlled" has two options:

• Occupancy - Only check logic for turning this light on when the area changes from clear to occupied
• State - Check at every state change The difference is that if you have lights configured for the sleep state, on the first one it will only turn those on if the area goes from clear to occupied and it's on the sleep state. The second will also turn those on if the area is already occupied and then enters sleep state.

See my configuration as an example:

Let me know if that helps. I've updated the wiki with this information

[andyinno]

Hi, Thank you for your detailed reply

I can confirm that 1 was ok. As visible in https://github.com/jseidl/hass-magic_areas/issues/144#issuecomment-950205052

There are no active sensors.

I think that 2 and 3 relates to the reason the lights are still on. Probably you are right, I do not understand how to correctly configure the states for getting the behavior that I would like to achieve..

I have 3 different usage scenarios. I would like to explain

1) livingroom

I have some ceiling lights that needs to be on when it is dark and the room is occupied. I have another couple of lights that I would like to turn on when the sleep status is active and someone enters the room. Basically they are some kind of service lights.

2) in the nursery if the baby is awake, I have a light that I want to be green (I configured it as accent light) if the light is green the baby can play 3) When it is sleep time the exact same light became red (sleep mode) no matter if there is motion or not. The baby is sleeping, therefore I need to provide a small light.

All the sensors that I use for room presence are motion sensors plus a couple of buttons for adding some extra command (enter sleep mode / enter play mode)

Reading the documentation it was my understanding that the 1 could be solved with

• motion detected
• sleep toggle active
• sleep lights operates At least this was working with the previous version of magic areas

2/3 using the state configuration for the lights Accent state set the light green and magic areas will keep it on Sleep state set the light red and magic areas will keep it on. The color would be handled by an external activation. I did not configure it yet.

The example that I was providing in my latest message was related to the fact that the extended occupancy seems to deadlock in some way. Once it is activated, it seems that it won't turn off again. How it is detected if the room state needs to go to clear if it is still active by the extended attribute? That's not clear to me.

Sorry for the long post.

[andyinno]

Sorry for the double post.

This is the configuration for 1 that I am testing. After your comment But... If I activate sleep mode overhead lights turns on in any case if motion is detected. The reason is that the ceiling light turns on in any case if motion is detected.

There is no option for telling if motion but no sleep, if motion but not accent.

Probably i was thinking about it as a default. And that's probably the reason it does not work as I expect. I was using this setup with the previous version of magic areas. If you enter in bedroom while someone else is sleeping, you don't want to turn on the ceiling lights. Just some small light that let you reach the bed.

[jseidl]

I can confirm that 1 was ok. As visible in #144 (comment)

There are no active sensors.

Even thou they're not active, they might have been and went off again. That's the only reason why the room wouldn't clear

For your use cases

I have some ceiling lights that needs to be on when it is dark and the room is occupied.

Those should be on the occupied and extended states.

I have another couple of lights that I would like to turn on when the sleep status is active and someone enters the room.

This needs to be set to sleep under States which lights are turned on. Also set When should lights be controlled to occupancy only.

in the nursery if the baby is awake, I have a light that I want to be green (I configured it as accent light) if the light is green the baby can play
When it is sleep time the exact same light became red (sleep mode) no matter if there is motion or not. The baby is sleeping, therefore I need to provide a small light.

You can set those to accent and not set to any state. You'd control these (the color changing behavior) by an external automation or switch. You'd also need to hold the presence while the baby is in the room otherwise the room would clear and turn that light off. You can also opt to exclude totally the light from the room if you feel so.

All the sensors that I use for room presence are motion sensors plus a couple of buttons for adding some extra command (enter sleep mode / enter play mode)

Just make sure the buttons toggle a input_boolean and use that input_boolean to trigger state, otherwise the state will be lost after the button clears.

Accent state set the light green and magic areas will keep it on Sleep state set the light red and magic areas will keep it on.

The feature doesn't provides any color control, only turn on/off lights. Magic Areas will keep it on as long as the room is occupied.

The example that I was providing in my latest message was related to the fact that the extended occupancy seems to deadlock in some way. Once it is activated, it seems that it won't turn off again. How it is detected if the room state needs to go to clear if it is still active by the extended attribute? That's not clear to me.

None of the secondary states influence on the presence, no state is used as presence sensor ever. The extended state is set if the room was occupied for over N seconds (configured) and that's it. Extended state will change the clear_timeout value but will not prevent the area from going off if there was no sensor trigger after the clear timeout period.

Whenever one of motion sensors triggers, it marks the area as occupied, whenever this motion sensor goes off and there are no other presence sensors (motion sensors in you case) on, it will then start counting until clear_timeout. If another motion sensor triggers during that countdown, the countdown is cancelled and further restarted when that sensor goes off. If all of your motion sensors stays off for over clear_timeout seconds, then the area will go clear (and your lights will turn off)\

There is no option for telling if motion but no sleep, if motion but not accent.

You need to not think in motion and start thinking on presence. Motion triggers presence. Lights react to presence, not motion. If the area is already occupied and you have a motion event, nothing should happen because the area is already occupied.

All light groups will only be on if the light is in the state they're configured to react. If you have lights set only to occupied then they should go off when you enter sleep. If you have lights configured to sleep they should go off when area loses the sleep state.

Set your lights to react both on state in addition to occupancy and you should see the behavior correctly.

[caphm]

@jseidl Sorry I haven't been able to contribute to this during the past months. I'm afraid I won't be able to in the foreseeable future, either, since me and my wife had a kid and I'm pretty swamped with work.

[jseidl]

@jseidl Sorry I haven't been able to contribute to this during the past months. I'm afraid I won't be able to in the foreseeable future, either, since me and my wife had a kid and I'm pretty swamped with work.

Brother, no need to apologize, your contributions surely rewrote the story of Magic Areas and I will forever owe you a beer for that. I'll pick up from here! Hope you can still use and report feature requests / bug reports whenever you have a break!

Congrats on the baby!

[andyinno]

Hi!

I just upgraded to the last code published. after the update the lights do not change their state anymore.

I reconfigured everything from zero but as the wiki states automatic light control needs to be checked in the configuration, I do not have this setting anymore.

Is the wiki still up to date or there is some difference here?

Thank you in advance

[jseidl]

Hey @andyinno, I've recently switched from the configuration "automatic light control" into making into a switch so you can switch light control on and off anytime. Look for a switch called "light control ($area)" and turn it on. Forgot to update the wiki, will do!

[andyinno]

Yup, the switch is created. Toggling the switch to on, lights are turned on and off.

Thank you!

[Bodge-IT]

Cool feature!

[andyinno]

Yes, cool feature.

I think more options, more personalization, means more possibilities and adapt to every user use cases

[jseidl]

Yeah I have guests sleeping in the family room/living room and trying to manipulate presence hold to keep the lights off was a pain. That shall solve it!

Furthermore folks, I've created a Discord server so we can have a tighter comms channel for the MA community, here's the link https://discord.gg/8vxJpJ2vP4

[klatka]

Using the beta I noticed a bug in attributes of created light groups. Instead of covers there should be a list of lights.

Example: light.lounge_lights

min_mireds: 153
max_mireds: 500
supported_color_modes:
  - color_temp
  - xy
color_mode: color_temp
brightness: 128
color_temp: 397
hs_color:
  - 28.827
  - 71.874
rgb_color:
  - 255
  - 159
  - 71
xy_color:
  - 0.546
  - 0.389
covers:
  - cover.level_schlafzimmer
  - cover.level_wohnbereich
  - cover.level_buro
  - cover.level_lounge
icon: mdi:lightbulb-group
friendly_name: Licht in der Lounge
supported_features: 40