-
Notifications
You must be signed in to change notification settings - Fork 44
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
The unit of sensor.wiser_lts [...] (°C) cannot be converted to the unit of previously compiled statistics (None). #434
Comments
Can you tell me if there are any automations or things that you do (such as turning off heating etc) in that room. |
It's just an example room, as I said, it's not always the same one. There are no automations at all with any of the room devices. Only a single automation within the hub itself, to switch the away mode based on geolocation. I don't think this is related. This triggers about once a week as we work from home, and it just toggles the thing. Here it is:
|
Just adding that after update to 2024.2.0 it's still happening, and I believe it has happened at the same time of the day than last time, and same sensor too... Will leave a note here and keep monitoring.
|
Please do as not seeing anyone else report this, so not sure why there is a stat entry with a None uom. I will dig into the code more but any further info on what manual or schedule actions might happen on that room would be helpful. |
Bingo.
Seems to be daily, at exactly the same time. There have been restarts and updates in between too. And at least these last few days it has been the exact same sensor. There are no automations handling this device as I mentioned, so I'm unsure what triggers this. Also, have a look at the logbook in the screenshot. Notice how the sensor (this happens with all wiser sensors repeatedly) becomes unavailable over and over, for only a few seconds, but very often. This is another issue that has been happening for a LONG time. I didn't want to raise it as I heard it was due to connection issues with the hub, but at this point I'm not sure if that's how all the users live. Don't think it's related to the topic here though, but just in case. |
I suspect it is related and this shouldn't be happening. Can you post screenshot as think you missed it. Can you also look at your hub signal entity attributes and see how long your hub has been up? Edit: sorry seen the link. |
Here: https://file.coffee/u/EJFxeDJkCOfjx7xfgQitV.webm Adding a few more errors from the log. Always assumed to be unrelated, and was planning to raise as issues at some point, but wanted to avoid overwhelming you... |
OK, I this is clearly your hub sending some erroneous data, which is the root cause of these issues. Need to think how we capture this to see what it is or whether I can check the data better and accommodate it. Give me a few days. |
I have just released v3.4.3 to fix an issue in passive mode. The update to the api included some better error handling for your issue. Can you upgrade and let me know if you still see these errors/different errors etc. Thx |
Lovely! Just updated, can confirm the HVAC error is gone as that one appeared right off the bat. But seems promising! Many thanks! |
Yep, new warning is showing again.
|
OK good (he says!) that's what I wanted to capture if it happened again. I'll look at this data and see what's wrong and if we can overcome it. |
Right, I think we have got to the bottom of the issue - whether we have got the fix is another question! :-) So, it seems your and @dpgh947 issues are caused by your hubs sending the response chunked. Previous work to fix the issues with changes in aiohttp, forced use of http/1.0 which does not support chunked responses. As such, you only get a partial response which is not valid json (and also not enough to be of use anyway). So the answer is to try and use http/1.1 (which supports chunking) and see if that fixes it out of the box or it needs something more to get all these chunks and put them together. My hub is not doing this (seems only a very few are), so would appreciate if you can try something for me to test if we have fixed it or need to do more work. In your config/custom_components/wiser directory you have a manifest.json file. In there, you will see a reference to aiowiserheatapi with a version of 1.5.7. Can you change this to 1.5.8, save the file and restart HA. Then tell me if you are still getting these errors or not. If this fixes it, I will release this update to everybody as it may be affecting more people than are reporting it. Thanks |
Mine is currently 1.5.5 (I'm on 3.4.2)...... I just looked on hacs and an update 3.4.3 popped up so I will install that first. I don't get these errors very often. |
I did so, it seems it's showing this message now:
|
See I almost knew that would happen!!! So, as schedules are very long, I thought that may chunk too but maybe not. Give it about 10 mins and change the same entry in manifest.json to 1.5.9 and try again. If you still get these errors (or back to previous error) then, think I'll have to rework some sort of retry routine as this is a very inconsistant issue (ie it works and then it doesnt and then it does and then it doesnt .. etc etc etc) EDIT: Good news however is it has got beyond where it was erroring before! |
Looks promising! 25min and no error after reboot so far. Will keep an eye and report back tonight or after 24h. |
To add more info. After every HA reboot now I'm getting:
|
Ok, so this is a royal PITA but I have made some adjustments to handle these response errors and issue retries. It seems to work on mine but can you give it a go. Amend the api version to 1.5.10 |
Updated. Will monitor for a few hours and report back if get any errors. |
Hows it looking? |
Actually... great! I was holding off to report good news just in case errors showed up later... but not a single error has shown up so far for this last 5h. Not after a couple reboots either. I have noticed the issue of all sensors going unavailable regularly, which I mentioned here. But apart from that, nothing in the log. Looks very promising. |
Ok, thats great but dont understand why all your sensors are going unavailable. Would have understood as updates were failing but now they are not, that makes no sense. I'll release this update as it has a lot of other fixes too and lets see how we get on. I have noticed on mine that the performance of some actions are slower now and this enhancement may need some more work to improve that but think we have the foundation to work with. |
Oh. It just came up, the daily error ar 21:05h again.
|
Yes, the fix for this will be in the release but you probably need to clear the history on it after updating. |
Just updated and the unit conversion error popped instantly now. What do you mean with clearing the history? Never done that before, not sure how it's done.
And also this new error has started appearing.
|
No, thats not the issue.
Is it just your climate entities going unavailable or all of them? I don't think they shouldn't go unavailable even if the hub fails to update. I'll need to check that. You could turn debug logging on for the api by adding the following to configuration.yaml:
and see if that shows anything. It will be quite a bit of logging to go through though. |
All of them. However for some reason the sensors don't show it on the history or logbook. Only the climate entity does. Ok, added the debug logs. Here they are. Cross searching the unavailable times, I can see the timeout matched the unavailable sensor at 18:31, but then the next ones didn't, and not even the debug log shows anything weird. You will also notice the log has some of the JSON decoding errors. But they are in the Debug level and not a warning anymore. Not sure if they are the same as past ones either. And their times don't match with the other 2 issues. |
So, they all match to a timeout but 1, so i focussed on that. If you look carefully, it never finished the update but no error of any kind (no attempt to get status and no update successdul with time taken). It then took another 5s before it went unavailable. Thats very odd - its like it just gave up. I wonder if it did timeout but the logging doesnt show this. I'll have a look at that. The question of why it times out so often but your wifi doesnt show it disconnected. Im wondering if it does disconnect for a short time and your wifi doesnt show if short. On your hub wifi signal sensor, what does your uptime look like? The json decode errors are fine. I am initially querying the hub on http1.0, which when the hub is not honoring this request properly and sends you a partial chunk, you will see it retries on http1.1 and is successful. It wil do this up to 5 times before it fails and it never does, apart from just timeouts. |
24 days uptime atm. You can also see the signal varies from very good, to good, sometimes medium. But the unavailable sections don't correlate to the medium or poor bits. |
Ok. Hold off on resetting your hub for a bit. I have a theory about the timeouts not being a http timeout but the async job that runs the update being cancelled before update completes as it took too long and it is actually that timing out. With more robust retry method it could be exceeding some timeout. |
So, spent more time looking at this and I don't think it is that but a hub connection timeout. I have included timeouts in the retry logic so if it does timeout, then it will try again 5 times. I have also increased the http timeout from 10s to 20s, so if your hub has dropped off wifi for a short time, it has 100s to come back on before it classes it as an update fail. I did notice with my mesh wifi though that after he hub has not been on wifi for 30s or so, it comes back within 3s with a connect fail (presuming dropped out of wifi device registry and gets a no route to host type error) and does not wait the full 20s. If yours does this then it may fail update much sooner. I have also added some more debug logging in the api to see what is going on and how long each request is taking when successful. And, I have updated the integration to stop entities going unavailable if the update fails. I'm not 100% sure about that as it seems to be standard HA functionality to do that if the update fails but I'm just too much of a crowd pleaser! It will still raise a warning in the logs as I think it should otherwise we are masking issues and it may not be easy to diagnose other symptoms. This will all be in v3.4.6 which I will release later. And then that will be the last release for a couple of months, but let me know how you get on. |
Thank you SO much for the hard work on this one. Eager to test it out and see how it goes on. |
Don't want to say it too loud just yet but... I updated to 3.4.6 this morning, and it's been 4h now and 0 errors in the log. It's true it's been in "Away mode" all this time since we're out, but I don't think that is related. I checked and sensors are still going unavailable at the same rate. But I feel it's great progress. |
Ok, checked through the log and it didnt fail update once but i did see the same update routine just didnt finish but no error or explanaition why. I wonder if HA is cancelling the task for some reason. Can you send me the logbook screenshot of one of these entities so i can see the times it went unavailable to match this log. This is bizzare! |
Rather than me release yet another version, can you also modify an integration file for me to see if we can capture something. In custom_components/wiser is a file coordinator.py At the very bottom of this file, you will see except Exception as ex: # pylint: disable=broad-except
raise UpdateFailed(ex) from ex can you change it to except Exception as ex: # pylint: disable=broad-except
_LOGGER.error(
"Unknown error fetching wiser (%s) data. %s. Please report this error to the integration owner",
f"{DOMAIN}-{self.config_entry.data.get(CONF_NAME)}",
ex,
) Make sure to keep the right indentation. I think this may stop them going unavailable but log an error in the logs as to what has happened. I think maybe somehow related to these updates that don't complete (either success or failure). You will need to restart HA for the change to take effect. |
Here. Did some OCR and formatting for easier read. chrome_RLiCHUqLAG 8 March 2024 Just saw your new message. Will check that now but leave this here in the meantime. |
Recording here for safe keeping. These are the times in your log see the issue of not finishing update. I expect these to correlate to your entities going unavailable. And, yes I can see it is happening a lot! 10:38:41, 10:56:25, 10:59:35, 11:13:38, 11:54:36, 11:55:10, 12:06:58, 12:15:38, 12:21:41, 12:24:19, 12:37:25, 12:46:13, 12:46:55, 12:51:57, 13:16:30, 13:45:00, 13:45:39, 13:54:16, 14:02:35 |
So yes they do correlate. If you can make the change above, I'm hoping we will see what it is in the log pretty quickly. |
Yeah, I did it 30min ago, but now the fucker hasn't gone unavailable yet. Will report back as soon as it does. |
I don't think it will but you should have some errors in your HA log |
Here it is, but I don't see any. At least not errors per se. |
OK, I can see the issue happening in the log but, I can't see an error logged either. This makes no sense! |
Yes spot on. |
No clue why then. Still no error or anything going unavailable. |
The dreaded 21:05 error about the units keeps happening immovable though. Log here, but doesn't say much. |
You would have to clear the statistics for this entity before this will go once the issue has been fixed. Go into dev tools -> statistics and fix in there. |
Yeah, that seems to have fixed that error. It hasn't showed up in 2 or 3 days now. Regarding the unavailable sensors, idk what's happened with it but the logbooks show completely empty now for the sensors. I have been messing with my db and I'm currently migrating, so it might not have anything to do with this issue. Will monitor once I'm done with the migration. |
Hey @msp1974, check it out. I don't have a clue what happened. I have now completed my db migration, but still, even before that, it's been 7 days now and not a single sensor going unavailable anymore (I find it even suspicious given I've rebooted HA several times and it doesn't show...). Also the issue about the units hasn't shown up either since I cleared the statistics one last time. So... I guess we can close the issue? Should I maybe reverse the manual changes you asked me to do? This and the API version. And getting the log back to normal. Let me know how I should leave them. |
Bump @msp1974 to close the issue as had no issues ever since my last message. Just would like confirmation what to do about the manual changes requested along the line. |
You can leave the changes as is and I will include them in the next release. I am leaving the issue open until it is released. |
Closing as now released changes in v3.4.7 |
For a while now I've been getting these types of warnings in the HA log. Usually once every day or so.
I'm not sure if it's always the same sensor or it keeps changing. I usually just follow the instructions and apply the "fix" as instructed. But that only solves the issue temporarily, until the warning shows up again.
I'm pretty sure the unit keeps getting changed from
None
toC
, and then back again. Which repeatedly triggers the warning even after it being fixed.Which led me to believe there is an actual issue with the integration. It's been happening for weeks if not months, over updates as well.
Integration v3.4.2.
HA:
HubR, with single channel, on a combi boiler without OpenTherm. Firm 3.14.0.
The text was updated successfully, but these errors were encountered: