OpenBK7231T_App
OpenBK7231T_App copied to clipboard
openshwprojects
I'm losing internet access after a few hours (sometimes days)
I'm experiencing some network issues. After some hours (sometimes days) I lose the access to the web page (no response). When I do a manual reboot I get access again to the page. Is this happening to someone else?
could be related to my issue https://github.com/openshwprojects/OpenBK7231T_App/issues/254 Maybe it's wireless is causing mqtt reconnects, and we lose something each time?
This is new. I had devices working with HA offline for days. Can someone - @btsimonh - check this commit? https://github.com/openshwprojects/OpenBK7231T_App/commit/b7db834c7b01538b6c4f39ac71521f3d27171a70 Can you guys check the older versions before this commit?
Other than that, I have no idea what could have changed.
Or maybe it broke... after @iprak MQTT queue implementation?
I don't know, please provide more information
The N platform had recently LWIP update, maybe we need to port it for T:
https://github.com/openshwprojects/OpenBK7231N/commits/master
Maybe we need this for T? https://github.com/openshwprojects/OpenBK7231N/commit/9f70b9cd745ed48ea3135332f7482d644d8e406d
That fix for N was needed because sending MQTT from "On Every Second" could cause rare threading crashes...
The MQTT queue only gets uses for HomeAssistant discovery and no space is upfront reserved unless discovery is manually invoked. MQTT can be sort of disabled by leaving host field empty .. maybe we could use that to check the interaction.
The only thing I see (cannot qualify most of the changes) is an increase from 1000 to 2048 in REPLY_BUFFER_SIZE. I have a feeling that we started with a LARGE value here, but slimmed it down, and now 'stream' to HTTP in small chunks rather than prepare large single buffers to send? (e.g. the purpose of hprintf128( ) is to allow the HTTP to be sent incrementally, so allowing very large data to be streamed rather than pre-prepared and posted).
Sorry guys for the late response. The version that I have: Build on Sep 1 2022 06:04:47 version 1.12.44 And yes, I'm using MQTT. I have a local broker on the network.
Just updated to the latest version: Build: Build on Oct 11 2022 05:42:17 version 1.12.103. Let's see if the problem persists.
i have them go offline as well. Home assistant says so. Once i activate the switch, its back
HomeAssistant uses the availability topic to determine switch's state. Currently, thi message is only sent out once in mqtt_connection_cb, so HomeAssistant does not know the state of the new switches.
For HomeAssistant integration to succeed, the device status should be routinely transmitted. This is not just for connected status but also for the various device parameters as switch state, dimmer value. It actually should also publish on the availability topic as well which it currently doesn't do.
Note that the status message is sent when switch is clicked and so HomeAssistant comes to know about it then. But if you restarted HomeAssistant, then the switch might again show as unavailable.
This effectively amounts to enabling "Flag 2" BROADCASTSELFSTATEPERMINUTE. This is located under "Config > Config General". The setting warns that it may cause device disconnect but that has to happen to sync device status. Try setting it.
This should all be resolved in .123 - re-open if it occurs again with that version?