2022.9: Home Assistant Birthday Release!

Got it working with the v3.8 update for my LYWSD03MMC. Thanks @solyxius and @Edwin_D.

I had these installed more than a year ago (no idea what version of ATC). Connected to them via the telelink flasher, installed v3.8 and set the advertising protocol to BTHome and they started to appear in the devices & services section :slight_smile:
image

Haven’t tried the plant sensors yet but this is a good start.

However I would still like to know how I can connect to the device for the log. At the moment I can only see the log when the ESP32 is connected to the laptop (via the Bluetooth proxy page - ESPHome Bluetooth Proxy). I see that the ESPs are “discovered” in ESPHome and can be adopted but not sure what this does…

Mentioning this because I didn’t see it searching the thread, but there is a pretty bad bug in the required version of zwavejs that prevents communication with certain devices (all of my Zooz brand devices in my case). The bug is documented here: META Issue: Communication problems on v10.x · Issue #4994 · zwave-js/node-zwave-js · GitHub

If you haven’t already, I recommend not updating until this is fixed if you have any Zooz devices. I wish I could safely go back and wait this out, but the next best thing is warning anyone else to avoid my fate.

Not intending to say there’s no issue… but for context, my zwave controller is a Zooz ZST10 stick, and I have ZEN15 and ZEN22 devices that have had no issues since upgrading to 2022.9.

2 Likes

Wow, I found myself in the same position. Would really love for Bluetooth_tracker to work again soon.

Thnx, indeed in the meantime updated as well.

I haven’t yet found the true reason for my HA crash yesterday but so far it appears to be caused by updating from 2022.8.7 to 2022.9.2

My issue is documented here.

More of a warning than error. I always seem to get a few of these.

ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
hass-nabucasa 0.54.1 requires cryptography<37.0,>=2.8, but you have cryptography 37.0.4 which is incompatible.

I think I’ve run into an inconsistency in the new (beautiful) Automations view. When I select a Timer as a trigger, I can’t select “active” or “idle”, only “on”, “off”, “unavailable” or “unknown”. Shouldn’t I be able to actually see the “active” or “idle” values rather than the generic “on”, “off”?

Those are translations in your selected language. After creating it, look at the yaml and it should have active or idle. If it doesn’t, that’s a bug, if it does, it’s your language.

Here’s what in the YAML after I created the automation in the IU, no sign or active or idle:

alias: Turn kitchen timer back on again
description: "Test af automatisk slukning af lyset i køkkenet "
trigger:
  - platform: state
    entity_id:
      - automation.kitchen_light_timer
    from: "on"
    to: "off"
condition:
  - condition: state
    entity_id: timer.light_kitchen_timer
    state: idle
action:
  - service: timer.start
    data: {}
    target:
      entity_id: timer.light_kitchen_timer
mode: single

Because your trigger is not using the timer entity… It’s using the automation entity.

That was embarrasing.

Updated: This time around the drop-down list boxes (from, to) only show “unavailable” or “unknown”. I had to type in “on” and “off”.

alias: Turn kitchen timer back on again
description: "Test af automatisk slukning af lyset i køkkenet "
trigger:
  - platform: state
    entity_id:
      - timer.light_kitchen_timer
    from: "on"
    to: "off"
condition:
  - condition: state
    entity_id: timer.light_kitchen_timer
    state: idle
action:
  - service: timer.start
    data: {}
    target:
      entity_id: timer.light_kitchen_timer
mode: single

Looks like timers don’t have state translations yet, so you have to manually put them in.

Check! :wink:

Should I point this out to someone or put a comment about missing state translation somewhere?

/// Bjarne

You can create an issue for it on github.

1 Like

The esphome proxies only support non-connectable/passive devices at this time. Support for connectable/devices that need an active connection is coming in the future.

You’ll have to add multiple adapters (usb to Ethernet extensions are great way to achieve this) to the local instance if you want additional connectable range at this time.

1 Like

I have a dozen Zooz devices and they’re all working fine after this update. Maybe a sporadic issue?

1 Like

It definitely could be. Possibly related to the Wave controller hardware even. I’m using an Aeotec Stick and it seems one of the posters above has no problems using a Zooz controller.

Got it. FWIW, I’m using a Silicon Labs UZB-7 USB Stick (Silabs SLUSB7000A / SLUSB001A).

I updated to zwavejs v10 in anticipation of updating HA and my Zooz Door sensor ZSE41 stopped reporting the open/closed state. It never went unavailable but it just never changed states.

I downgraded back to v9 and it’s working again.

But my Zooz motion sensor worked with no issues on either version.