Right now Persons ONLY accepts device_tracker entities. Ping sensors are not allowed, so for me this serves no purpose at this time. We’ll see as time goes on if it brings anything of substance for my needs.
1 Like
You should post an issue at the github for the custom card.
Anyone else with high cpu loads after update?
I get these randomly and normalizes after a restart of HA. Using a nuc5i5.
thanks for the advice but unfortunately it’s not a card developed by any one person. it was more of a component I hacked together for my own use using info from a couple of different threads.
The good news is that I ended up getting it sorted out from a tip on the issue I opened on the polymer github - just use a button instead of a mwc-button. duh…
Anyway, it’s all better again, now.
1 Like
Oh, I didn’t understand that 
Glad it’s solved!
1 Like
I am getting same high cpu usage but using Glances add-on I see that it is MotionEye fault.
I need to investigate more
Something that wasn’t communicated very well that was explained to me in the last few days is that the changes to ZHA make it act more like Z wave. Now, when the Hass starts, it basically polls the network and takes a few minutes to become ready, just like Z wave, whereas it used to just work right away. I’m under the impression this results in a more stable network, but I don’t know that for sure.
I thought my stuff was broke at first as well, but after a few minutes, they came to life. On the very first boot, there were a few battery powered Zigbee sensors that I had to force a wake up (e.g. open the door it was connected to) so that it updated the system. Its like they had to register one time with the new ZHA changes to read properly. Then Hass read that device properly from then on. I’ve been running .88.1 for a few days with about 25ish Zigbee devices, and so far so good.
There is also a “Reconfigure Node” option in the ZHA menu now too. If you choose a device that isn’t reading properly, this may help it. Same caveat with battery powered devices though. You may need to wake them up right before you “reconfigure” it.
2 Likes
Hey, thanks for that explanation.
I thought my zigbee stuff was starting to get screwy because after a restart it took a while to start working ok.
Thanks for the info. Everything is up and running on 0.88.1 now and so far so good!
I do not use MotionEye I think… I have a rtsp camera configured, but that’s not the same is it?
I am using the Notify component with the xmpp platform. I am no longer receiving messages after upgrading to 0.88 / 0.88.1. Doesn’t work when I call the service manually either. Any others seeing this?
Function Call:
notify.ha
{“message”:“Test”}
Results in log:
2019-02-26 21:03:39 ERROR (MainThread) [homeassistant.core] Error doing job: Fatal error on transport TCPTransport
Traceback (most recent call last):
File “uvloop/handles/stream.pyx”, line 827, in uvloop.loop.__uv_stream_on_read_impl
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/xmlstream.py”, line 406, in data_received
self._spawn_event(xml)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/xmlstream.py”, line 970, in _spawn_event
stanza = self._build_stanza(xml)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/xmlstream.py”, line 951, in _build_stanza
stanza = stanza_type(self, xml)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 1390, in init
ElementBase.init(self, xml, parent)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 416, in init
if self.setup(xml):
File “/usr/local/lib/python3.7/site-packages/slixmpp/stanza/stream_features.py”, line 27, in setup
self.values = self.values
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 615, in _set_stanza_values
self[full_interface] = value
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 753, in setitem
lang=lang)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 959, in _set_sub_text
return self._del_sub(name, lang=lang)
File “/usr/local/lib/python3.7/site-packages/slixmpp/xmlstream/stanzabase.py”, line 1040, in _del_sub
parent = self.xml.find(parent_path)
File “/usr/local/lib/python3.7/xml/etree/ElementTree.py”, line 299, in find
return ElementPath.find(self, path, namespaces)
File “/usr/local/lib/python3.7/xml/etree/ElementPath.py”, line 307, in find
return next(iterfind(elem, path, namespaces), None)
TypeError: ‘NoneType’ object is not an iterator
I am using a Tellstick Duo with a set of temperature sensors. When starting HA 88.x I get this warning in the HA log:
Your configuration contains extra keys that the platform does not support.
Please remove [57], [183], [124], [71], [224], [151]. (See /home/homeassistant/.homeassistant/sensors.yaml, line 87).
Here is the part of the configuration that is likely to cause the problem:
#
- platform: tellstick
57: Soverom
183: Loftet
124: Kjeller
71: Midten
224: Tv_stuen
151: Stuen
only_named: true
temperature_scale: "°C"
datatype_mask: 3
#
As fare as I can se this is according to the documentation: https://www.home-assistant.io/components/tellstick/
Anyone who knows how to work around this?
I added two devices - iPhone (tracked via iCloud and FritzBox) & Apple Watch (tracked via FritzBox) - to my Person. When going out for a run - only carrying the Watch with me and leaving the Phone at home - my status switches back to “home” after a couple of minutes. I guess that’s because the Phone is still at home.
Is there a way to get the correct status (=not_home) when tracking two devices, even when one of the devices stays at home?
I very much doubt that… this is where the Bayesian sensor would help… but seriously how can it possibly differentiate?
Thanks, I will have a look at the Bayesian sensor.
In case of device_tracker the device with the “not_home”-state should overrule the device with the “home”-state. When tracking more than one device for a person it’s likely that one is left at home.
Or has a flat battery.
Have a look at monitor component, forget routers
I just updated to 0.88.2. While I managed to get rid of all the breaking changes, there is one error I am unable to get rid of.
I am using Telegram Bot via webhooks and my HA is installed on Docker in Synology NAS. To get it working, I have to put my local IP into the trusted_networks key as described in Getting Telegram webhooks working with Nginx.
Unfortunately, 0.88.2 gives this error…
Your configuration contains extra keys that the platform does not support.
Please remove [trusted_networks]. (See /config/packages/telegram_bot.yaml, line 5).
If I remove trusted_networks from the telegram configuration, it stops working.
Anyone else facing this issue?
Looks like it needs a issue report on github. The docs still say the trusted_networks is valid. https://www.home-assistant.io/components/telegram_bot.webhooks/
At least it is only a warning at this stage.
yeah… it’s confusing. the documentation said it’s valid but the error says otherwise. will open a report soon. thanks anyway.