-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
No connection or no stable connection to bridge #6
Comments
looks like the connection is not really stable in your LAN to the bridge - I have to admit that I am clueless what is the default (if at all) timeout for an aiohttp session - so in the new (beta) version https://github.com/marq24/ha-tibber-pulse-local/releases/tag/1.0.8 I have added a timeout of 10sec for each request - please update and let me know the result... TIA |
Unfortunately it didn't fix it, my wifi rssi is -67, so this should not be an issue. Any idea how i can test if the connection is stable? |
I have to admit - for now I don't have any additional idea... what I have understood so far, that "sometimes" you can add the bridge - but once its added, it does not deliver data (most of the time you see "unbekannt"... Can you please be so kind and enable the debug-log for the integration and share here the log output that will be generated [obviously this requires, that you have been able "once" to connect to the bridge...] ... and IMHO also worth a try is this what's reported here in #3 (change the battery) |
Correct. Batterie looks fine:
so hope this helps |
For the start I would increase the polling interval... to 10 - 30 sec |
just as explaination - the LOG reveals that there is no connection error - it's that the data stream the tibber bridge is providing is "corrupted"... You "can" see invalid chars in the byte sequence... I have the same here @ home from time to time - but that that frequent as your... Do you have another application/service running elsewhere querying the data from the same tibber bridge? |
The interval was 10s und changed it now to 20s No nothing, only the tibber cloud is active. |
Concerning all the CRC Errors in your log... First of all - there is no communication error/issue in your setup - the HA integration can reach your tibber bridge without any problems - the "only" problem is, that the (a lot of) responses (the actual byte-sequence) that the bridge is providing can't be decoded. This sounds first hand like a problem of the integration - but this is not the case - it's the response (bytes) that the bridge replies to the request of the integration are not in a valid format (famous developers words: "it's not my fault" :-D )... As I wrote earlier - I have here also from time to time this CRC errors in the log - and obviously in the first days I tried to dig deep into the code (and in the library that I use to decode the SML-message) to find the root cause of the problem - and at the end of the day I had to realize, that the INPUT (the byte sequence) is simple not correct. So no way for "my code" to get around this - "shit IN will always cause shit OUT"... When I was looking closer into the byte sequence (and that's the only reason why I log it in HA), I saw, that the "valid starting message" will interrupted at random places... and a new message start byte sequence is starting. (at least I believe so) Here is my "theory" what is happening inside the tibber bridge (without having any proof) - IMHO the web server component build into the bridge have a "shared buffer issue" - IMHO the server is not thread save - this means that before a response have been completely written into the output-stream the response-byte-buffer will be reused by another incoming-request... So mainly two processes use the "same" memory in order to provide a response... and this will lead to the situation... When some of the requests (in your network) will take 5 sec - others just 1 - then there the chances are quite high, that the tibber brigde have to process multiple requests at the same time - causing "both" responses to be invalid (or at least one of them)... Again this is just my theory - I don't have any real proof of that - but at least I can say, that the code of the integration seams to work "fine" in your current setup - there is no unexpected behavior (which I initially thought would be the case)- it's just that the data that is provided by the bridge are invalid sml byte sequences. :-/ |
Ok, could it be, that the tibber cloud is causing this issues? Can i deactivate that and see if ithelps or do i have a faulty bridge? |
I can't recommend to deactivate anything at the tibber setup... And I do not believe that your have faulty hardware... With the move, that we have enabled the web server in the tibber bridge permanently, we are the ones who make a move away from the default configuration - so we can not expect, that "everything" just works... Also open a support case would not be smart IMHO... since we are doing something different. IMHO we just can accept the situation as it is - and try to play around with alternative update intervals and see, if this would change the situation... In my local setup the Bridge and the Pulse are aprox. 1m away from each other - and the Bridge is 40cm beside the WLAN router - so this is for sure the MOST-stable environment possible... I just can guess, what will happen if the distance between theses three components would be increased... Could be that the CRC error rate would increase here as well... |
Bridge and Pulse are around 5m apart and my accesspoint 8m. I installed a new seperate home assistant and made the integration their, but still the same issue. What I don't understand, why the cloud works "perfect", and the data is their also not corrupted? |
The "cloud" use a total different communication - Your Tibber bridge reads the data from the pulse and send's it over via MQTT to a central MQTT Server running at AWS... There are users who step in the middle of this communication, and adjust the bridge settings that the MQTT data will be send to a local MQTT instance and then from there to the Tibber cloud... I just can assume, that the code doing this (read the data from the pulse and send it via MQTT) would work rock solid (intense tested by Tibber SoftwareDevDepartment) - Could be that the code making the data also available via the Webinterface is simply submitting the "last data buffer" that was used by create the MQTT message - and that there is no sync? When the MQTT-part is fetching new data, the webserver should wait till the data was read completely - but again this are all just theories... I am not claiming, that the integration is working rock-solid for million other users and you would be the only one facing this issue - nor do I have an idea, what "else" you can try to improve the "unavailable" situation - (IMHO it's better to see "no data" instead of providing just previously fetched (aka old) values)... |
I disagree on that one, because if i open my dashboard it would be better to see my last consumption then nothing. Ok so it seems i need to accept the situation and use the cloud integration again. Thank you for your help. |
took me a while to understand which specific statement you disagree... so there is now a 1.0.9 |
Thanks, that helps |
Can confirm there CRC messages:
I attached a "longer" log. |
... so @ckarrie looks like that you are "caught" in the same situation as @Bloodydead - I am sorry but I am still clueless what could be the root cause for the CRC errors - well one thing is very easy - the CRC error(s) occur cause the read byte sequence from the bridge is not valid... BUT why this is happening - and why so often in your environment is totally unknown... Here in my setup I have a CRC once or twice a day... that's it. Concerning Entities with value "Unbekannt" - when the integration starts it will request |
These CRC Errors causing the initializing setup problems in #8 too. I just setup a dev environment and its shown in the log while trying to connect to the bridge |
I fixed it for me @Bloodydead :
|
@ckarrie wow, i never thought about rotating the pulse head, because the tibber app received the data. It also worked for me. Some crc errors, but much better then before. Thank you :) |
just found this... so rotating the pulse head is also in the tibber docu... |
Hey,
i tried to install your addon. Webserver is running and responsive.
I tried every version from 1.0.2 to 1.0.7 sometimes i get a connection but then the sensor values are 95% of the time "unbekannt"
or i get an error if i try to set it up with "failed to connect" or "Es konnte keine Daten abgerufen werden"
Under Nodes i can see "last seen" is between 0.5s and 4s
Meter Type is SML 1.04
Model: Landis & Gyr E220
I have an encoded output
Hope you can help.
Thank you in advance.
The text was updated successfully, but these errors were encountered: