-
Notifications
You must be signed in to change notification settings - Fork 8
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
{BUG] Attributes for an Entity may exceed maximum allowed Size when using RT Data #54
Comments
|
Yes, it is only for my Zones (=multiple Sensors) with RT Data. I can easily turn that on/off. So yes, i turned a Zone beeing static, and that was still (again) working.
With JSON you mean the debug_file, right? Yes, that keeps updating.
Sure! As this happens only with RT Data, i could simply trigger the Problem and log it. Maybe i focused on the wrong Line - maybe this from the attached log is somewhat more useful? If needed yes i can set up the constant debug log and go for a hunt!
|
And your rt url is in the sensor or ... via the service call and then use a reference to the rt-file? |
I guess you use the service call while it would allow you to embed the changing api-key. Further guessing is that 'sometmes' you cannot get the data from the external url for whatever reason and thus the thing crashes. The json will not update with the same pace as it needs the rt first. When you have a 1kb rt, can you please open it and examine the content ... as it is 1kb I assume it contains an error from the rt-providing side, posisbly apikey mismatch or timeout. I need to know a bit more on how to |
Yes, like that.
But why would it continue to update the debug_file? Isnt the *_converted.txt build from the *.rt, should't that stay empty or not get created at all?
Oh my, why am i so stupid? I once looked at a correct *.rt file, didnt understand anything, and then just forgot to recheck 😵 Yet, i don't understand how the debug_file can get created, if it depends on the *.rt File... |
It cannot, I am near to 100% sure that you look at the result of a previous run. From the file-content above, I cannot resolve this untill ou can demonstrate it is somewhere in the process :) |
Describe the Bug
Sometimes (i have the feeling especially at Peak Times) all Zones (Stops) using RT-Data, with all their Sensors fail and render unavailable.
All *.rt Files for all Stops/Connections going 1kb. The debug file *_converted.txt still seem to work, Filesize (~800kb) and Date changes.
Zones (Stops) only using Static Data are unaffected, disabling RT-Data for that Zone and reloading makes them available again.
In Logs i can see e.g.:
WARNING (Recorder) [homeassistant.components.recorder.db_schema] State attributes for sensor.241722_local_stop_zone_haltestelle_test_ma_hbf exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored
Steps/data to reproduce the behavior:
Download the static GTFS: https://rnv-dds-prod-gtfs.azurewebsites.net/latest/gtfs.zip
Register for the API Key for RT-Data: #51 (comment) and use them
Set up a Zone with some Stops
Enable RT for that Stop with *.rt as Source
Reload, see the next Departures
Wait for a crowded Time 😝
See all Sensors going unavailable
Release used
gtfs2: 0.4.4.7
HA: HAOS
Core: 2024.4.3
Additional
See Attachment
example log for rt data causing attributes overflow.txt
The text was updated successfully, but these errors were encountered: