Thank you.
1 Like
Will this work if I identified the 433 Sensors for my windows and doors as binary sensors?
THe mqtt message looks like you catch it
homeassistant/sensor/ge {“time” : “2018-05-21 16:59:59”, “model” : “Interlogix”, “id” : “xxxxxxx”, “device_type” : “contact”, “raw_message” : “611430”, “battery” : “OK”, “switch1” : “CLOSED”, “switch2” : “OPEN”, “switch3” : “CLOSED”, “switch4” : “OPEN”, “switch5” : “OPEN”}
I specified them as so:
- platform: mqtt
state_topic: “homeassistant/sensor/ge”
name: “Back Door”
payload_on: “OPEN”
payload_off: “CLOSED”
qos: 0
device_class: door
value_template: ‘{% if value_json.id is equalto “xxxxxx” %} {{value_json.switch1}} {% else %} {{states.sensor.back_door.state}} {% endif %}’
Yes, but you’ll need to create an mqtt sensor for the battery. Make sure it either has battery in the name or has device_class set to battery.
1 Like
Thank you very much. I will try this tonight.
Good evening.
After do the delete of old mqtt cache date ‘the retain mqtt message’ I got error with mqtt on all devices that use mqtt.
After restart ha many many time. mqtt come back and show unknown of battery from mqtt
from mqtt process
1527253200: Received PINGREQ from homeassistant
1527253200: Sending PINGRESP to homeassistant
1527253205: Received PUBLISH from homeassistant (d0, q0, r0, m0, ‘owntracks/diana/dianaiphone/cmd’, … (41 bytes))
1527253205: Sending PUBLISH to homeassistant (d0, q0, r0, m0, ‘owntracks/diana/dianaiphone/cmd’, … (41 bytes))
1527253206: Received PUBLISH from homeassistant (d0, q0, r0, m0, ‘owntracks/me/suniphone/cmd’, … (41 bytes))
1527253206: Sending PUBLISH to homeassistant (d0, q0, r0, m0, ‘owntracks/me/suniphone/cmd’, … (41 bytes))
I may not have given you the right topic name. Can you use mosquitto_sub to check to see the right topic name and clear it? Another option, if you’re using hassio, is to uninstall/reinstall the mosquitto addon, which will wipe out all retained messages.
I tried this updated package but it seems “battery_sensor_from_battery_level_attribute” is triggering alot.
Is this suppose to happen?
Every 5-10 mins it triggers 10-15 times in a row…
It will get triggered any time there is a state change for an entity that has an attribute named “battery_level”. When you see it happen 10-15 times in a row, is it for the same entity or different ones? Which component(s) generated the entities that you are seeing this issue?
Thank you so much for this awesome package. I installed V1.0.7 about a week ago and I like it.
Just two things I wanted to share with you.
I have a few Xiaomi Dorr and Window Sensors, those are working great and they get detected as % as it should be.
But I also have Window Sensors from Homematic and also Thermostats from Homematic and those two devices are showing up a bit wierd.
The Thermostat is reporting its battery in V (Volts) of the actual battery that inside the device. That gets picked up by your script and gets rounded to a whole number to make it a % battery sensor. So the reportet 2.6V from the device become a battery sensor of 2%.
The Window Sensor from Homeatic reports its battery as High, Medium or Low. But it somehow comes out as 0%.
I attached 4 screenshots so that you might be able to understand.
Any help would be great
I’m working on a feature that should be able to help with this one if you know how to create a template that converts 2.6V to % or if you know what voltage represents low battery. If you know, it would help me if you could share that info so I can validate whether it will work with the feature I’m working on.
I see the issue with this one. I’ll work on a fix.
Awesome package. For sensors that do not report about battery level directly but do a check in periodically (e.g., 24 hours) can you add a template to trigger if something has failed to check in within a certain period?
Thanks! That might be possible, but I’m not sure how to identify which devices are battery powered if they don’t have a battery attribute. Do you have any examples you can share? It would be helpful to see a screenshot of them from the /dev-state page so I can see their attributes.
Version 1.0.8 is now available at Home-AssistantConfig/packages/battery_alert.yaml at master · notoriousbdg/Home-AssistantConfig · GitHub
Added
- Add support for defining battery_template attibute to
allow manipulation of value of battery sensor - Support battery attributes that contain strings
Removed
- Cleaned up notifications by removing object id
Try using the new battery_template feature in this release to either convert volts to % or “Low” when it’s less than a certain voltage. There are some examples in the documentation section that should help.
This should be fixed in this release.
Any idea to make this excellent code as an Addon?
This way HA will display when a new version is published and the update is done with a button.
Just some wishful thinking.
Cheers.
1 Like
I like the way you’re thinking. That’s an awesome idea. It should be pretty easy to do.
Its normally genereated by the same entity, but its not the same entity every time.
It seems its related to zwave battery powered devices.
Example:
Thanks for the very fast update.
I will get that integrated during the next days.
Will let you know how it works out.
The automations only trigger on state changes. There must be reason why that device is updating it’s state so often. Can you look to see why that z-wave device is sending so many state changes?
Release 1.0.9 is available now. I finally figured out how to automatically create a group that contains all battery entities. If you created a Battery Status group manually, you can remove that from your config.
Installed version 1.0.10 (Hassio 0.71.0) and I am not getting a “group.update_battery_status_group_members” in my DT-Sates overview.
Should I?
I can see the “Update Battery Status Group Members” option in the “group.battery_alert”-view in my HA.