search

technyon / nuki_hub

Use an ESP32 as a Hub between a NUKI Lock and your smarthome.
MIT License
501 stars 39 forks source link

8.35: config changes triggered in Home Assistant triggers complete MQTT reload for that device (renders all entities unavailable) #434

Closed bcutter closed 1 month ago

bcutter commented 2 months ago

PROBLEM DESCRIPTION

After updating NH from v8.26 to v8.35, when one config (e. g. switch.lock_door_b_led_enabled) is changed, first the switch immediately turns back and after few seconds all entities are unavailable - it takes 30 seconds for them to come back. Nuki Hub seems to NOT restart during that time according to the sensor.lock_door_b_uptime_nukihub sensor.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

Nuki Hub version: 8.35 Nuki Hub build: 9596430697.1135.1 (release) run: true confVersion: 835 deviceId: [MASKED] deviceIdOp: [MASKED] nukiId: nukidOp: mqttbroker: [MASKED] mqttport: 1883 mqttuser: mqttpass: mqttlog: false checkupdates: true websrvena: false lockena: true lockpin: 1 mqttpath: nuki_door_b openerena: false openerpin: openercont: false mqttoppath: maxkpad: opmaxkpad: maxtc: opmaxtc: enabtlprst: false mqttca: mqttcrt: mqttkey: hassdiscovery: homeassistant hassConfigUrl: buffsize: dhcpena: true ipaddr: [MASKED] ipsub: 255.255.255.0 ipgtw: [MASKED] dnssrv: [MASKED] nwhw: 1 nwwififb: false rssipb: -1 hostname: ESP-Nuki-Hub-Door-B nwbestrssi: true nettmout: -1 restdisc: true rstbcn: 60 lockStInterval: 3600 tcPerEntry: false kpPerEntry: false configInterval: 3600 batInterval: 7200 kpInterval: 1800 kpCntrlEnabled: true kpInfoEnabled: false kpPubCode: false tcCntrlEnabled: false tcInfoEnabled: false cnfInfoEnabled: true regAsApp: false regOpnAsApp: false nrRetry: 10 rtryDelay: 100 crdusr: crdpass: *** disnonjson: false pubAuth: true pubdbg: false prdtimeout: 60 offHybrid: false hybridTimer: 600 hybridAct: false hybridRtry: false hasmac: true macb0: -41 macb1: 80 macb2: 112 latest: 8.35 tsksznetw: tsksznuki: authmaxentry: kpmaxentry: tcmaxentry: MQTT connected: Yes Lock firmware version: Lock hardware version: Lock paired: Yes Lock valid PIN set: Yes Lock has door sensor: No Lock has keypad: No Lock ACL (Lock): Allowed Lock ACL (Unlock): Allowed Lock ACL (Unlatch): Allowed Lock ACL (Lock N Go): Allowed Lock ACL (Lock N Go Unlatch): Allowed Lock ACL (Full Lock): Allowed Lock ACL (Fob Action 1): Allowed Lock ACL (Fob Action 2): Allowed Lock ACL (Fob Action 3): Allowed Lock config ACL (Name): Disallowed Lock config ACL (Latitude): Disallowed Lock config ACL (Longitude): Disallowed Lock config ACL (Auto Unlatch): Disallowed Lock config ACL (Pairing enabled): Allowed Lock config ACL (Button enabled): Allowed Lock config ACL (LED flash enabled): Allowed Lock config ACL (LED brightness): Allowed Lock config ACL (Timezone offset): Disallowed Lock config ACL (DST mode): Disallowed Lock config ACL (Fob Action 1): Disallowed Lock config ACL (Fob Action 2): Disallowed Lock config ACL (Fob Action 3): Disallowed Lock config ACL (Single Lock): Allowed Lock config ACL (Advertising Mode): Disallowed Lock config ACL (Timezone ID): Disallowed Lock config ACL (Unlocked Position Offset Degrees): Disallowed Lock config ACL (Locked Position Offset Degrees): Disallowed Lock config ACL (Single Locked Position Offset Degrees): Disallowed Lock config ACL (Unlocked To Locked Transition Offset Degrees): Disallowed Lock config ACL (Lock n Go timeout): Allowed Lock config ACL (Single button press action): Allowed Lock config ACL (Double button press action): Allowed Lock config ACL (Detached cylinder): Disallowed Lock config ACL (Battery type): Disallowed Lock config ACL (Automatic battery type detection): Disallowed Lock config ACL (Unlatch duration): Allowed Lock config ACL (Auto lock timeout): Disallowed Lock config ACL (Auto unlock disabled): Disallowed Lock config ACL (Nightmode enabled): Disallowed Lock config ACL (Nightmode start time): Disallowed Lock config ACL (Nightmode end time): Disallowed Lock config ACL (Nightmode auto lock enabled): Disallowed Lock config ACL (Nightmode auto unlock disabled): Disallowed Lock config ACL (Nightmode immediate lock on start): Disallowed Lock config ACL (Auto lock enabled): Disallowed Lock config ACL (Immediate auto lock enabled): Disallowed Lock config ACL (Auto update enabled): Disallowed Network device: Built-in Wi-Fi BSSID of AP: [MASKED] Uptime: 0 minutes Heap: 76228 Stack watermarks: nw: 7096, nuki: 5536, pd: 7096 Restart reason FW: RestartOnDisconnectWatchdog Restart reason ESP: ESP_RST_SW: Software reset via esp_restart.



### TO REPRODUCE
Update NH to 8.35. Make a config change through any Home Assistant configuration entity.

### EXPECTED BEHAVIOUR
Change is performed immediately and the changed entity updates within few seconds, all other entities are not affected and no entity renders `unavailable` for 30 seconds.

### SCREENSHOTS
https://github.com/user-attachments/assets/bd7a78b1-d7bb-4636-8eb1-9f5f2d8165e8

### ADDITIONAL CONTEXT
This makes controlling a Nuki lock from Home Assistant using Nuki Hub pretty useless.
- I can directly compare the behaviour to another Nuki Hub still running NH v8.26 - which works flawlessly when doing config changes.
- I enabled MQTT integration debug logging and performed a config change for that Nuki Hub device and had an intensive look at the log afterwards but can't really find anything suspicious.

**(Please, remember to close the issue when the problem has been addressed)**
mundschenk-at commented 2 months ago

Can't reproduce with build 9909162422.1186.1 (an early 8.36/9.0 build). But how often do you change your config settings that this seriously affects your use of the lock in HA?

bcutter commented 2 months ago

Well it's more that it doesn't really give confidence when the stability in Home Assistant is so massively negatively affected by an update of a 3rd party component (from outside HA trough MQTT). I've never seen this before in the last years - and this issue makes using HA to configure Nuki locks pretty useless.

What else can I provide or test?

mundschenk-at commented 2 months ago

We will be certain to forward your experience to the QA department.

It's not your fault, but this issue report does not help much. You skipped 12 versions, so we have no idea from the report when something changed. It's also not for the latest version of the code, so the issue likely has already been fixed (as I was not able to reproduce it on a later version).

bcutter commented 2 months ago

Why isn't the report helpful? What do you need (I added a demonstration video now). I believe this is not really acceptable:

https://github.com/user-attachments/assets/06ef174d-ebb8-467c-a8be-efbb4cb7df54

Do you want me to update step by step from 8.26 up to 8.35 with a stop-by at 8.28, 8.29 etc.? I have a second Nuki Hub on 8.26. But this way we'd also only know which release introduced this behaviour - is that helpful at all?

Or any other ideas?

mundschenk-at commented 2 months ago

At this point in the release cycle, I don't think it is worthwhile to put more energy into investigating this issue. If you can reproduce it with 9.0 when that is released, it will become another matter (but I don't think you will see issue with 9.0).

bcutter commented 2 months ago

More facts after testing:

  1. reloading the whole MQTT integration takes a long time until the NH 8.35 updated device shows values in normal (not grayed out) color again.
  2. after that, most entities have NO valid state at all, most are unknown and therefore configuration interface is strange too:

grafik

grafik

  1. I need to manually press the buttons Query battery and Query config etc. and wait quite a while (1 to 2 minutes) to get status back for many entities, however, many others stay in unknown state now:
    • sensor.lock_door_b_nuki_hub_build
    • sensor.lock_door_b_nuki_hub_ip
    • sensor.lock_door_b_nuki_hub_latest
    • update.lock_door_b_nuki_hub_firmware_update
    • sensor.lock_door_b_rolling_authorization_log

Those only switch to their actual values once I restart the Nuki Hub.

Something's fundamentally broken here. Worst update experience so far :-)

And the fact no one else ran into this makes me feel very uncomfortable to just "sit and wait for 9.0". I hope this is reasonable.

mundschenk-at commented 2 months ago

You can try cleaning up the nuki and related config topics in the broker while NH is switched off. There might be some retained messages that wreak havoc with HA discovery. Other than that, I really don't know what to tell you. You might need to renew your support contract with @technyon and @iranl 🤷

bcutter commented 2 months ago

I tend to ignore the passive funny support contract comments :-)

You can try cleaning up the nuki and related config topics in the broker while NH is switched off. There might be some retained messages that wreak havoc with HA discovery.

How would I do that?

  1. Power off Nuki Hub
  2. Start MQTT Explorer and delete all topics from
    • /nuki_door_b/
    • /homeassistant/sensor/nuki-id/*
    • same as line before for lock, binary, switch, number, update, button, update and select instead of sensor
  3. Power up Nuki Hub again - and pray everything is recreated

Is that correct?

As it's my productive system I really don't want to loose any data (settings / references, custom icons or I don't know what else gets removed when basically "purging" the MQTT).

mundschenk-at commented 2 months ago

I tend to ignore the passive funny support contract comments :-)

Maybe don't label things as "unacceptable" or "worst update experience" then?

You can try cleaning up the nuki and related config topics in the broker while NH is switched off. There might be some retained messages that wreak havoc with HA discovery.

How would I do that?

  1. Power off Nuki Hub
  2. Start MQTT Explorer and delete all topics from
  • /nuki_door_b/
  • /homeassistant/sensor/nuki-id/*
  • same as line before for lock, binary, switch, number, update, button, update and select instead of sensor
  1. Power up Nuki Hub again - and pray everything is recreated

Is that correct?

Yes.

As it's my productive system I really don't want to loose any data (settings / references, custom icons or I don't know what else gets removed when basically "purging" the MQTT).

If you want to make sure that HA does not lose any entity customizations, you can shut down HA or disable the MQTT integration while you clean up the retained messages. It's unlikely to be necessary, but if you want to go really sure, that's the way to ensure that HA can't do anything funky.

Anyway, MQTT messages (even retained ones) are only a kind of message bus, so they are always ephemeral.

bcutter commented 2 months ago

Unacceptable refers to the situation and few comments like "just wait for the glorious 9.0 release which is unknown when to arrive or if it will fix things at all" :-D :-D :-D

Back to business. Additional notes:

That plus the fact a Nuki Hub restart at least triggers a value update from MQTT to Home Assistant leaves me quite wondering - and more or less clearly pointing at Nuki Hub - which also is the only thing changed (likely to have introduced this).

I need to decice which way I walk tomorrow: a) purging MQTT content as described above b) downgrade Nuki Hub from 8.35 step by step to see if/when this resolves (at latest at 8.26 I guess) c) upgrade my second Nuki Hub from 8.26 to 8.35 in minor steps and see if and when the same behaviour starts d) test 9.0 beta release (I could not find the compiled esp32 .bin yet) e) wait for 9.0 stable / 8.36 release

Plenty of options basically. Unfortunately I already spent half of the day (unbelievable I know!) only for Nuki Hub stuff. Let's call it a day for today.

Appendix: restarting the MQTT broker surprisingly triggered the update entity: grafik

The MQTT topic looks like this: grafik

Where the hell is 8.26 coming from?!? It never got updated since the update today (8.26 to 8.35). That's not a Nuki Hub bug (but speaks more for option a) above), isn't it?

After deleting the topic and restarting Nuki Hub it looks fine: grafik

mundschenk-at commented 2 months ago

Well, nobody told you to do those additional steps, so please don't complain that they took time. The mysterious value indicates that you have old state messages retained by the broker and should clear out those topics (I have noticed a similar thing on my installation, it seems the retained flag was changed sometime in the past for some topics).

technyon commented 2 months ago

@bcutter Please acknowledge that everyone here is doing their best to help you. What Nuki Hub does is complex on many levels, and problems can occur. HA auto discovery in itself is complicated enough already to potentially cause problems. Every release is tested as much as we can without being a commercial project. I know it can be frustrating if things don't work, but that's in the nature of setting up your own smart home.

I can't be all that helpful since I'm not a HA user, but maybe deleting the MQTT nodes related to Nuki Hub sounds reasonable, since a fresh Nuki Hub setup doesn't show these problems. Maybe export customizations you made before so it's easy to add them later.

bcutter commented 2 months ago

I'll test to purge the MQTT content (Option a) from above) and turn back.

The fact that after restarting HA nearly all entities are unavailable/unknown reminded me of the very root issue which blocked me (with old HA setup before 2023.8) from updating NH to 8.27 and beyond:

https://github.com/technyon/nuki_hub/issues/227

But that time only the lock entity was affected - and the instability issue I see currently wasn't a thing either. So just thinking out loud - as mentioned I will report back after the MQTT topics cleanup test.

bcutter commented 2 months ago

After going through https://github.com/technyon/nuki_hub/issues/434#issuecomment-2246236813 (with disabling the MQTT integration before and enabling it again after the process), nothing has changed:

So a) from this list did do nothing unfortunately.

a) purging MQTT content as described above b) downgrade Nuki Hub from 8.35 step by step to see if/when this resolves (at latest at 8.26 I guess) c) upgrade my second Nuki Hub from 8.26 to 8.35 in minor steps and see if and when the same behaviour starts d) test 9.0 beta release (I could not find the compiled esp32 .bin yet) e) wait for 9.0 stable / 8.36 release

Which option do you recommend now next?

bcutter commented 2 months ago

OK I continued with

b) downgrade Nuki Hub from 8.35 step by step to see if/when this resolves (at latest at 8.26 I guess)

I downgraded NH from 8.35 to 8.34. Results:

a) https://github.com/technyon/nuki_hub/issues/433 is fixed (or not yet introduced), battery voltage is back grafik

b) behaviour regarding this issue is at least improved: no full device entities reset for ~ 30 seconds, instead it just flickers for a moment and after few seconds the command seems to be executed and confirmed back (by MQTT to HA). That's the way it looks and feels at least - and right in the moment when the switch changes to its final (desired) state I can watch the MQTT topic /nuki_door_b/configuration/ledEnabled change its state):

https://github.com/user-attachments/assets/ddfae711-96b6-429c-98c7-badd8ca4e86a

Not yet good (not as fast and direct as with 8.26), but much more stable.

So no idea what introduced (or increased the outcome of) this issue in https://github.com/technyon/nuki_hub/releases/tag/8.35 (maybe Update nuki ble library?), but 8.34 seems to be the MUCH better choice for now. ...which of course is no permanent solution.

Here's a config/system information comparison of v8.35 (before the downgrade) on the left and v8.34 (after the downgrade) on the right:

grafik

**1. Do you spot any difference which might in combination with 8.35 changes look "suspicous"?

  1. Can someone provide a working .bin for ESP32 of the 8.36 / 9.0 beta? I want to test if this issue only is/was 8.35 release specific or if we continue to carry that around in future releases.**

Afterwards I continued with

c) upgrade my second Nuki Hub from 8.26 to 8.35 in minor steps and see if and when the same behaviour starts

✅ 8.26 to 8.27: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.27 to 8.28: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.28 to 8.29: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.29 to 8.30: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.30 to 8.31: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.31 to 8.32: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ✅ 8.32 to 8.33: stable. instant updates in MQTT broker (and back in HA) when changing config from HA --> MQTT ⚠️ 8.33 to 8.34: same behaviour like for first NH: change interrupts for a few seconds. takes time until config change is performed/confirmed in MQTT topic and synced back to HA. See video above, it's the same behaviour now for this Nuki Hub. ⚠️⚠️ 8.34 to 8.35: same behaviour like for first NH: massive interruption with a break of 30 seconds to reload all entities, see video in original post. Therefore also downgraded this NH-ESP to 8.34 which is at least roughly working.

Summary based on all these investigations:

  1. Everything fine until NH 8.33
  2. 8.34 introduced the connection/state update interruption/delay issue
  3. 8.35 increased this issue intensively
  4. Therefore I doubt this slowly introduced issue (first in 8.34, then extended in terms of impact in 8.35) will be suddenly fixed in a 8.36 / 9.0 release. Therefore please support to investigate.
  5. I also noticed the assets provided for every release changed with - interestingly - 8.34 release. I choose esp32-assets.zip, unzipped it and used the nuki_hub_esp32.bin to upload it to my ESP (LOLIN32 Lite Board V1.0, ESP-32 Rev1). That's correct, isn't it?

So the ultimate question is: why started this with 8.34? Wild guesses from a non-dev looking at https://github.com/technyon/nuki_hub/releases/tag/8.34, starting with the ones reading the most interesting:

Update Arduino Core to 2.0.15 (won't build otherwise using Actions/Dockerfile) Update Nuki BLE library Fix config query interval Modify existing config Home Assistant auto discovery topics Add every config and advanced config option to MQTT (JSON)

iranl commented 2 months ago

The behaviour you are experiencing with 8.34 is correct and by design.

Before 8.34 when you used a Nuki Hub config switch in Home Assistant it directly modified a combined state and action MQTT topic. In 8.33 and before this meant the switch will show the intended change immediately but will not reflect the true state of the setting in the Nuki device. The behaviour in 8.34 is much improved from this original behaviour but has the mentioned downside in Home Assistant because it takes a couple of seconds to change the setting in the Nuki device and request a new config from the Nuki device to confirm the setting has actually changed.

Home Assistant has no setting that can be changed to specify the expected waiting time for the state topic to change after publishing a command to the action topic. This causes the switch to momentarily change back to the original position before moving to the intended position. This momentary situation will not fire a event though, so automations are not impacted by this UI issue.

Why you are experiencing different behaviour in 8.35 from 8.34 I can't explain.

I suggest using a program like MQTT explorer to look at how the MQTT topics change when you change a setting in Home Assistant and comparing the difference on your setup between 8.34 and 8.35.

Expected behaviour when changing a setting in Home Assistant:

Also keep an eye on nuki/maintenance/mqttConnectionState, this should remain online at all times

Please report back with any differences between 8.34 and 8.35 while observing the above.

technyon commented 2 months ago

Also, here's a link to the latest beta binaries:

https://github.com/technyon/nuki_hub/actions/runs/10086733497

Note that you'll need to flash via serial because the partition scheme has changed. Setting will not be overwritten if you don't do a factory reset.

bcutter commented 2 months ago

The behaviour you are experiencing with 8.34 is correct and by design.

OK, quite a difference and not perfect from a HA user/UI perspective, but as mentioned: fine for me. I consider 8.34 as stable. It's just the complete outage of the 8.35 release this issue is about.

Please report back with any differences between 8.34 and 8.35 while observing the above.

8.34 with Nuki Hub number 1:

  1. HA: make a change to switch.lock_door_X_led_enabled
  2. ✅ Immediately: nuki/configuration/action changes to { "ledEnabled": "1" } and changes back to --
  3. ✅ Shortly after 2: nuki/configuration/commandResult changes to {"ledEnabled":"success","general":"success"}
  4. ✅ Shortly after 2: nuki/configuration/basicJson changes (ledEnabledand currentTime), nukihub/configuration/advancedJson remains unchanged (as the tested LED is not stored here)
  5. ✅ HA: LED switch changes to desired state - whole process takes roughly 3 seconds
  6. ✅ nuki/maintenance/mqttConnectionState remains online during the whole process

8.35 with Nuki Hub number 2:

  1. HA: make a change to switch.lock_door_X_led_enabled
  2. ✅ Immediately: nuki/configuration/action changes to { "ledEnabled": "1" } (nothing more!)
  3. ❗Nothing happens for roughly 23 seconds.
  4. ❗nuki/maintenance/mqttConnectionState switches from online to offline and all entities of the device turn unavailable in Home Assistant.
  5. ❗18 seconds where nothing happens (neither in MQTT nor in HA) - seems like the Nuki Hub is doing "something".
  6. ❗Now kind of a "big flash update" happens in MQTT where many topics get updated within one second, among others:
    • nuki/maintenance/mqttConnectionState switches from offline to online
    • nuki/configuration/action changes back to --
    • nuki/configuration/basicJson gets updated
    • nuki/configuration/commandResult gets updated
    • at the same time in HA: all entities are available again and LED switch changes to desired state ✅ - whole process takes roughly 44 seconds.

Please also note that the NH is constantly available via WiFi during the process and also according to my sensor.lock_door_X_uptime_nukihub sensor (grabbing Uptime from /info) NH does not get restarted.

If I wouldn't be concerned bout few visible details (IDs, lock names etc.) I would share a video recording of HA on the left and MQTT Explorer on the right side. Along with the time code you can see exactly what I described above in plain text.

So obviously something happens in Nuki Hub because of the

How to (remotely) gather logs of the Nuki Hub/ESP itself, would that be helpful? I could compare the 8.34 NH with the 8.35 NH that way.

Also, here's a link to the latest beta binaries:

https://github.com/technyon/nuki_hub/actions/runs/10086733497

Note that you'll need to flash via serial because the partition scheme has changed.

Oh it's a nightly, I thought it's a branded beta - doesn't matter. A serial flash is already kind of a downer, in general. Thinking of where those ESPs are mounted/hidden, the downtime of this process... well, it is as it is. Much more interesting:

Would I be able to downgrade (probably doing a serial flash again) to 8.35 (or 8.34 which is kind of stable instead of the horrible 8.35) again without loosing data?

iranl commented 2 months ago

Thanks for the update. Based on your report I found the offending code:

https://github.com/technyon/nuki_hub/blob/4d4edaf126f3b8c6c58288bb576d164ee88b1132/src/NukiWrapper.cpp#L1158

Setting this value to true causes a delay of up to 30 seconds in processing the next command. It should have been set when another BLE command was running but in this case was always set when processing config changes.

This code was added as part of #389 and removed as part of #407. 8.35 was released in between these and contains the problematic code.

So this is already fixed as part of 9.00.

You would be able to downgrade to 8.35/8.34 using a serial flash if you update to a 9.00 pre-release without losing data. 9.00 will also allow you to export and import all your configuration and pairing data.

The best binary to be on right now if you want to test 9.00 would be https://github.com/technyon/nuki_hub/actions/runs/10095506815 imho as this includes latest fixes for BLE connectivity. I also run this build myself on my non-development ESPs.

bcutter commented 1 month ago

OK I'm sitting here for half an hour trying to figure out how to flash the https://github.com/technyon/nuki_hub/actions/runs/10095506815/artifacts/1739771030.

  1. https://technyon.github.io/nuki_hub/ does not let me choose a specific version, instead, it just wants grafik

  2. Espressif Flash Download Tools is very complicated (right the start screen: factory? developer? what?!?)

  3. esptool: following the how-to-flash.txt the commands (--before default_reset --after hard_reset) indicate, I will loose my configuration

So finally, here's the question: what is the most convenient way to flash that beta version without loosing the whole configuration? That information will be needed for the release notes anyway, won't it...

iranl commented 1 month ago

  1. Webflash will only be updated when 9.0 is officialy released. We might do beta and/or dev version over webflash in the future.

  2. No default and/or hard reset don't erase settings

bcutter commented 1 month ago

Sad to hear (web flash).

So once again:

what is the most convenient way to flash that beta version without loosing the whole configuration?

And when will 9.0 make it to a stable release? I need to decide if I really want to spent more hours on this or sit and wait with 8.34.

iranl commented 1 month ago

I'd say remain on 8.34 and use webflash when 9.0 is released.

9.0 will be released when we feel it is done, could be in a week, could be in a month depending on how many bugs are found.

bcutter commented 1 month ago

I'd say remain on 8.34 and use webflash when 9.0 is released.

That's exactly what I decided to do 15 minutes ago.

Looking at https://github.com/technyon/nuki_hub/milestone/3 it seems there's not much to do left, but I guess that's not an arithmetic thing (like "only two issues left, let's push it next week" :-)).

I'll update to stable 9.0 once available by webflash, test things quickly and turn back here to hopefully report "issue is fixed, thanks". Until then it's fine for me to leave this issue open, thank you.

iranl commented 1 month ago

Closing with the release of 9.0.

bcutter commented 1 month ago

I've seen the 9.0 stable update (already discovered by one of two NHs).

Unfortunately because of the breaking change

The presence detection feature has been removed.

I first need to try migrating two presence detection scenarios away from NH before I can finally test 9.0 release.

Because of this removal it might be one now has to double the devices (one ESP for NH, one for presence detection), which also doubles maintenance, power sockets, power costs, ... and increases complexity. Understandable decision (based on the issues presence detection created according to the release notes because for me it was working very very good) but from a users perspective not really sustainable.

Off-topic over, I'll turn back with 9.0 test experience feedback once presence use-case drop is solved.