-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE]: sensor state should provide clear information #66
Comments
Hello, Regards
` |
Thanks for this...in a few cases it is indeed related to the card and not refreshing. What I seemed to see is that a sensor where the state = stop name...and the state does not change ... it goes stale. The challenge I have is that I cannot pinpoint a 'when'. Current ideas are to change the state from stop_name to number of stops (from the attributes) so it changes along the day. HA behavior is not 100% known to me, I ma be able to develop bits/pieces...does not mean I am a devloper :) |
Well i have seen a strange behavior a couple of weeks (months?) ago. |
It is quite tricky to repoduce things as I often donot have the same source or the time to look at things that are not 'my data of interest'...anything you can provide may help me to understand where the code may go pearshaped :) |
Hi , I just found this https://community.home-assistant.io/t/how-to-make-template-sensor-with-as-timestamp-update-regularly/106084/2 In short it says "It is possible to force update even if sensor value doesn't change...."... may be it cound help with your update/refresh .... On my side the issue is related to invalid timestamp when processing: |
Thanks and I was indeed thinking about a state-value that changes, which is not the stop-name. ...still pondering |
Describe the solution you'd like
At present, when tje config leads to a no-data situation, afetr a while the sensor goes to unknown, which can mean multiple things
Describe alternatives you've considered
Static start/end: currently shows first/next departure
=> unknown seems pretty accurate as it is not known when a next dpearture takes place, could change to something more descriptive as "next-departure-unknown"
Local-stop sensor: currently shows stop name
=> stop name in a state is not really a good location, possibly change to number of collected departures
The text was updated successfully, but these errors were encountered: