-
-
Notifications
You must be signed in to change notification settings - Fork 59
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] Lost connection to wall panel #39
Comments
I just login to report exactly the same issue, I have random disconnections since I installed v0.10.1, no problem with the latest beta (v0.10.0-beta1). |
I rollback to version https://github.com/TheTimeWalker/wallpanel-android/releases/tag/v0.10.0.1 and I can confirm I do not reproduce bug that occured in the morning after boot. From my memory, this version suffered of the same issue that, after a while, sending a mqtt message to switch camera can sometimes "disconnect" wall panel. |
Hey, @TheTimeWalker can you try to te reproduce the issue ? Or maybe @FredericMa you can rollback your modifications about MQTT reconnection in #29 ? (But keep battery sensor reconnection fix) |
I've created PR #47 that should handle all MQTT disconnects. Before, only one particular type of disconnects would have been handled. My expectation is that this solves this issue but it doesn't clarify why the disconnects happen while using the camera. |
@Clement-B I was able to reproduce it myself before but haven't come around for a fix. Thanks to @FredericMa there's a possible fix. I'm keeping this issue open just to be sure. Please try out v0.10.4 as soon as it's available in the Releases section and report back if that fixes the problem |
Thanks a lot @FredericMa for giving a try to fix this issue and @TheTimeWalker for creating a new version! I will install the new version right now and will give you my feedbacks after a few days. Hope this fix the issue 👍 |
So, it has been 2 days since upgrade. As a reminder, here is my routines with wall Panel:
I monitor MQTT connection status with a custom binary sensor in HA : binary_sensor:
- state_topic: "wallpanel/mywallpanel/connection"
name: "WallPanel - Connection (custom)"
payload_on: "online"
payload_off: "offline" What I observe is:
To illustrate what I get, here is some history of the sensor in HA (I checked logs and there is no delay between logs and history): You can see all the reconnections phases between 12 pm/2:30 pm and 7 am/9 am. If we focus on a morning, you can see the duration needed to reconnect (seems quite long) and connection becoming stable again after I trigger manually camera when connection is fine: So the conclusion of my tests are:
As a reminder, here was the state of my connection with version v0.10.0.1: Network connection is not issue I think as my wifi router is at a few meters of the tablet. So questions are :
|
What I see from my side are 32 events with these two exceptions from your device: Is your Wi-Fi more polluted right now? Is the graph from the older version a bit older, or is that what happens right now as well? Also, have you checked that your MQTT broker isn't closing all the time accidentally now? Lastly, have you checked that the app isn't getting battery optimized? |
I'm actually seeing the same behavior (screenshot from MQTT broker): Specs: I searched a bit and found this for the paho mqtt client: hannesa2/paho.mqtt.android#7 @Clement-B: it is strange you face this issue on Android 7 since this particular issue seem related to Android version >= 8. Can you verify the tablet runs on Android 7? |
We're not using Paho. We're using HiveMQTT since v0.10 beta0 |
True but that PR describes a way to solve exactly the same issue we see here, by creating a foreground service notification. I reviewed my recent changes but I can't see any change that could induce this behavior. I have the feeling that the code below, that was previously in both the MQTT 3 and 5 service, covered this issue up by accident: wallpanel-android/WallPanelApp/src/main/java/xyz/wallpanel/app/network/MQTT3Service.kt Lines 103 to 123 in 169dae5
@TheTimeWalker if you feel more comfortable with reverting my changes feel free to do so. |
I use Mosquitto broker add-on from HA.
I confirm my tablet run on Android 7. One thing to note is my tablet is fixed on a wall near a corridor so we used to pass a lot near during the day where camera is triggered each time. So I was thinking that when tablet enter in a state of connection unstability, it would be cause by a long idle time without triggering motion and screen on. After checking this hypothesis, I found that instability can come just after a few trigger in v0.10.14: But with the previous version, I found out that connection may become unstable just exactly after 1 hour without motion detection (and screen on) detected, see below: |
Here is some logs from mqtt broker if it can help, we can see a strange error where username, cloent id is not found, dont know if it's related to wall panel.
|
For the error: Are you trying to connect to your broker as anonymous / without username and password? It sounds like this issue: home-assistant/addons#2474 |
@Clement-B Can you please also take the time to create a debug log of the previous working version (v0.10.0-beta1)?
You can also see that the publishing of the state only happens every 2 minutes instead of every minute as defined in the settings... |
I created PR #48 for this. With these changes, no disconnects appear and the sensors are being updated every minute (default update interval) as it should. These changes might impact battery life since the CPU won't be turned off anymore so this is something to be monitored. |
I'm not connecting to broker as anonymous but you linked to the right issue. I no longer see username error in mqtt broker logs. It was caused by I think old retained messages like explained in the issue you linked. Also, this morning, I dont get the unstability (multiple disconnections each 2min) that I usually have. But it could be a coincidence as if camera is turned on when connection is on, wall panel become stable again. And tonight, I reproduced it again after I think multiples camera requests throught mqtt. Here is the log of MQTT for the last disconnection tonight.
On thing I didnt mention is I use a mqtt switch configured in HA to enable / disable camera (previously I was using a simple script in HA), here is the configuration with the retain option : mqtt:
switch:
- command_topic: "wallpanel/mywallpanel/command"
name: "WallPanel - Camera switch"
payload_on: '{"camera":true}'
payload_off: '{"camera":false}'
state_topic: "wallpanel/mywallpanel/state"
state_on: True
state_off: False
value_template: "{{ value_json.camera }}"
retain: true
availability:
- topic: "wallpanel/mywallpanel/connection"
I can try this if it can help.
Nice finding here! Unfortunately, I do not know much about android dev otherwise I will have tried to do a code review. |
Just adding a datapoint here since I was struggling with tablets loosing connections and went down a rabbit hole of trying Fully Kiosk Browser as well as the HA companion app. Running a wakelock manager with the following settings enabled seems to keep the tablet's connected (ie preventing Android from throttling wifi / cpu). I ended up using the following settings in https://github.com/d4rken-org/wakelock-revamp and seem to be able to maintain a solid connection (approx 2% packet loss over and hour of pings). It would be nice if these wakelock options were incorporated into the app.
|
Description
After some time or specifc actions, I lost connection to wall panel , here is my observations:
To restore Wall Panel, I can:
Informations about my configuration:
Steps to reproduce
Bug occure when :
Sometime, there is day with no disconnection, sometimes it's 2 or 3 times a day. Right now, Wall Panel seems to disconnect every morning after boot since a few day.
Versions
Some logs
Logs form HA, when trying to enable camera and loosing connection from Wall Panel
Maybe something important to note here is my system have sent in the example 3 or 4 MQTT messages to Wall Panel to enable or disable wall panel camera within like 25 seconds.
The text was updated successfully, but these errors were encountered: