Hey thanks for the fast response
Can I find from the log which automation is it?
I can only try and find it through the automation.yaml file, cuz as I mentioned I don’t have a automation page anymore…
As described in the added picture
Tasmota integration now forces the use of %prefix% in MQTT FullTopic. That should be labelled a breaking change since it nullifies MQTT binary_sensors that do not expect the addition of the prefix.
1 Like
I recommend creating a separate thread and I can help you there. You’ll have to post your automations in yaml.
I hear you on the delay - I actually replaced my essentials bulbs with zigbee versions as a stopgap until thread support was available. But i saw this update and pulled them out of a drawer to test it out- now it’s lighting fast with Thread. I also setup an essentials light strip with thread.
To that end, check out the HomeKit Controller integration documentation- there’s updated instructions to use Thread. In short, pair it with HomeKit first, make sure you have a HomePod mini or newest Apple TV as they act as border routers, and then delete it from HomeKit without factory resetting the device itself. Once you remove it from Apple, it should show up in HA discovery where you add it as a device like you would normally would. If you run into issues, make sure your HA and HomePod mini are on same VLAN and make sure you have IPv6 setup in HA settings - this was my issue as I had it disabled for some reason.
I had to delete the config, and start all over from an empty UI page. it’s back now, thx
aware this is valid yaml
service: zwave_js.refresh_value
data:
entity_id:
- switch.in_wall_toggle_switch_500s
but so is
service: zwave_js.refresh_value
data:
entity_id: switch.in_wall_toggle_switch_500s
in fact, if we dont need lists, we shouldn’t write them shouldn’t we? Isnt this sort of a bug? the UI only accepting a list, even on a single entity…
btw, WTH… keeps on going…
this really is off putting, and we can not disable that, because then we need to completely disable the iBeacon integration…
You might also consider applying any available firmware updates with the Nanoleaf app before removing it from HomeKit
Normally when you report a bug you get a response within a few hours but this time it has been quiet for over 2 releases already and I am forced to stay stuck in release 2022.06.7. I have reported this bug under number #75437 , Hassio Add-on #207 and AppDaemon issue on HA supervised #1551. The problems do not occur with HA OS on a Raspberry. It does occur on an Intel NUC running HA Supervised. Appdaemon does not start up properly and displays an error message. In addition, the log is filled up at a rapid rate. I do have 20 Gb available on the hard drive but still after a while I get a message that I am starting to run out of free space. I turned off Appdaemon and that did stop the log filling. So it indeed seems to be due to Appdaemon but again only on a HA supervised. You cannot update to Supervisor 2022.07.1, Supervisor 2022.09.0 or Supervisor 2022.10.0? I even tried to run Appdaemon in docker on another machine but with the seem error: Can’t connect. Retry in 5 seconds…'Unfortunately I don’t have enough knowledge to dive under the hood. Who does?
The service code is implemented to allow lists of entities (using entity_ids validator). Form a UI perspective it’s much nicer to be able to select multiple entities without having to drop into YAML mode. However, maybe this a rare use-case, and the common use case of a single entity is preferable (you can just call the service multiple times). Feel free to submit an issue if you disagree, and someone can make the decision to revert it. Technically it is probably a “breaking” change as it does affect the UI, unfortunately I didn’t realize that was the case, as the service code still worked properly.
I agree that it would be preferable to support both formats (a list or single item), like target selectors allow. Unfortunately, the multiple entity selector does not support a single item, in contrast to the target selector. A target selector cannot be used because the service call currently only accepts entity IDs, not device IDs, and allowing selection of devices would encourage bad behavior (refreshing too many values unnecessarily has a negative effect on network performance).
1 Like
SwitchBot have quite a few products that use Bluetooth. Their temperature sensors are more affordable than WiFi ones, and they’re detected by HA immediately.
What’s the battery life on those?
restored 20022.9.7
I got error messgages with my current automations.
error line 19 which persists even if i delete the whole automation.yaml content…
Claimed life is one year. I’ve had mine for two months now and it’s still showing 4/4 bars on the display and 100% battery in HA (but I don’t know how precise that is).
Sorry for the barrage of questions, but I don’t like my xiaomi temp sensors (the new version). So these are just instantly seen by the network if you have ble proxy setup?
As soon as I got my custom-fw ones to advertise as Mi-Like, they started popping up (even on 2022.09):
@petro What is exactly your “issue”?
The new xiaomi temp/humidity sensors requires you to load them into the app first in order to get a key for use. It’s really dumb. They also switched them from a AAA battery to a CR2025 and the battery life went from years to months. And on top of that, the battery reading coming from the device is straight up wrong sporadically throughout the day, i.e. the firmware is filled with bugs.
TLDR: The rev2 version of the xiaomi temp/humity sensors are bad in every way. They made a complete regression with the devices from rev1 to rev2.
Version of the sensor is: CGDK2
2 Likes
Yep, as is the Govee .
Had 6 different BT sensors all doing exactly
the same. Only kept the Govee, it’s rather nice and immediate. Also ga e a better impression than the Switchbot, which was more expensive…
No promises on the battery though , only have them since the Bt proxy addition to HA
1 Like
It would help if you linked the issues rather then dropping numbers. There’s a TON of repositories in the HA ecosystem
So that is this closed issue that was filed in the wrong repo right?
And then I’m guessing that’s this one?
Don’t know what’s wrong but there’s certainly a lot more context in the discussion at the second link if anyone did want to help.
EDIT: Actually wait
Why not? I mean not 2022.10.0 since that’s only on the beta channel right now. But you should be able to update to 2022.09.1
To be clear on bluetooth beacons with esp32, they only add to existing bluetooth adapter range and cannot serve as the main bluetooth adapter? So I would have to have a USB bluetooth adapter on my ODROID N2+ but with esp32s scattered around, they would add to this to increase the range?
Also, it seems like my esp32 has lost the BLE tracking logs if I flash it with the active proxy config, it is no longer saying “Device found” etc., can it not function as both? Or is this just a logging change?
So all my V1s of these were popping up just like yours. The v2 version requires the bindkey and they will not appear unless you know the bindkey. Which is a pain to get. Anyways, I highlighted above why the second version is not good.
1 Like