Closed Anto79-ops closed 2 years ago
Here's actually a better photo of the history...you can see on monday its 2, then teusday its 1, then wednesday (collection day), the state goes back to 2.
please send diagnostics and logs from the collection day. Thanks. I did not change that logic, so I do not know what is wrong.
ok, i will check the logs, there was nothing in the HA core logs about the garbage collection day, but I could look again next week ...but you can try testing this yourself, now if you wish....
I made a new test garbage sensor via the helpers, made the collection day tomorrow, and saved it. State was 1. Then I updated the sensor to make the collection day today, saved it, the sensor updated BUT the state was still 1. Should it change to 0?
ah ha! Here is the log file that just appeared, and it makes sense a calendar issue..is this a local issue for me or a bug?
This error originated from a custom integration.
Logger: homeassistant.helpers.entity
Source: custom_components/garbage_collection/calendar.py:143
Integration: Garbage Collection (documentation, issues)
First occurred: 1:51:12 PM (155 occurrences)
Last logged: 4:50:12 PM
Update for calendar.garbage_collection fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 514, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 709, in async_device_update
raise exc
File "/config/custom_components/garbage_collection/calendar.py", line 48, in async_update
await self.hass.data[DOMAIN][CALENDAR_PLATFORM].async_update()
File "/config/custom_components/garbage_collection/calendar.py", line 143, in async_update
entity_id = min(next_dates.keys(), key=(lambda k: next_dates[k]))
TypeError: can't compare datetime.datetime to datetime.date
Right, that helps. Thanks. I am testing it, and there are number of automated tests that run for each release. But I did not spot the issue. here is what it shows to me.
This is why I asked for diagnostics that include your configuration so that I can replicate exactly what you have. Or try to figure out where it comes from. Anyhow, now I have something, I will dig deeper.
Can you try 4.8.2b1 if it fixes the issue? I could not replicate the issue, but did few changes that might potentially fix that. Thanks. But since I could not test that, I release it as beta first.
thanks @bruxy70 I'd be happy to share whatever you need!
I downloaded and tried the beta version 4.8.2b1, unfortunately, its not operating as intended.
Here's what I did after updating and restart of HA:
I created a new test sensor. Today is Thursday and set collection day to Sunday. After pressing submit the sensor correctly reported a state of 2. However, after changing the collection data to Friday (tomorrow) and even today (Thursday) by pressing submit, finish and update. The sensor state still remained in the state of 2.
Please let me know how I can help with this.
Also, if you need to know my versions:
Home Assistant 2022.7.4 Supervisor 2022.07.0 Operating System 8.3 Frontend 20220707.0 - latest HACS 1.26.2
Just tried the b2.. Now, unfortunately it does the same thing as my previous observations for b1.
Strangely the icon of the test sensor does change correctly to what the status is but the state of the sensor does not change.
If you want I can email you a link where you can actually see this live on my desktop through Google Desktop, if it'll help for troubleshooting.
Thanks. Got it. I think this is a different issue than the last one. I believe you do not get the error anymore. And if I am right, it will update at midnight. I think the issue now is that the update is blocked even after changing the options. I will look at that when I gave the access, probably tomorrow.
thanks for being such a responsive developer. Ok, I'll give it a day or 2 before I try again and keep you posted. Cheers
No worries. You can always buy me a coffee 😊. I believe I found what was causing it. I tried to extend restoring the state to more attributes, so that the entity would be available right after the restart and will not wait a minute or so for recalculation. I thing this was blocking the update when options change (not sure, but I believe this is it - please confirm). I will try improving it going forward - removing the stored values when oprions change, or forcing the re-calculation. But for now, I removed the state restore functionality and I am only restoring the last_collection_date, like before. Let me know if that works.
thank you, the new update works!
Coffee bought and well deserved!
Cheers
Before you submit a new bug report, please check that
Write your question here
Hi!
Just wanted to ask something (as im not sure if this a bug or usage issue), since the new update, I've had some interesting issues or perhaps is just me not using properly. But for example, today was collection day, and the sensor went from 2-1 but then back to 2 on collection day
I doubled checked the sensor configuration, and it indeed is setup for wednesday (today) collection.
One thing I noticed with the new update is that when the entries show up in my calendar, it now has a time infront of the entry of 12:00am, which makes sense, but perhaps its not setup as an all-day event and that could explain why it skipped the 0 state? Before the update, the calendar entry had no time in front of it.