[network] Incorrect Timestamp Update After Restart in Network Binding #17404
Comments
lenschith
added
the
bug
lenschith
changed the title
|
Agree, to me it also seems wrong to set the channel I must say that this only occurs at binding start. Because the state update is forced immediate after the binding is started. This is due to a Test jar openHAB 4.2.x+: https://1drv.ms/u/s!AnMcxmvEeupwj4tJIT-V2IgG3v0MUA?e=gDdt6a
|
|
I tested this today according to the instructions, but couldn't see any improvement. it's still the same behavior this value is contained in the mapDB, RestoreOnStartUp UNDEF is still displayed in the item |
|
Could you verify the used binding version from karaf console? Double check the stock version is not running alongside. |
|
I hope this are the correct information.
before reboot. MobilePhone online Container rebootet, MobilePhone offline (MobilePhone WLAN Connection disabled) the item shows UNDEF. I add a rule to fill the item with the previous state. but you can see, the next check change to UNDEF too! |
|
There is another location that sets the lastseen channel to UNDEF. (line 149). To fix this it is not enough to just remove it. From the bindings perspective it is totally fine to set the state to UNDEF as there is no value from the bindings pov. Also the lastseen channel is read only, so setting the command won't work. Created a new jar, this should make the channel writable so if you perform the exact same tests i would now assume it is fixed. |
|
Hello I have test the New JAR Restart the Container, MobilePhone WLAN disabled The state set to UNDEF?? Check the mapDB Persiststate. (RestoreOnStartup) Set the Item with the previous State After I set the state manual with a Rule. The Networkbinding did not change the state again to UNDEF The new state if the Device online again, where written to the Item But why is the last value still overwritten with UNDEF when the container starts? Actually, this should work without manual intervention with a rule? Regards Lenschi |
|
The binding can only react to a command from openHAB. Later on you send a command (by a rule) and the binding reacts to that by setting the internal state / I hesitate to continue with this as
The best solution might be to drop the whole UNDEF setting in the binding. To me it makes sense. But this might not be agreed on by others. Could you tell something about the actuall use-case / issue you have ? Does it cause issues with some scripts running or otherwise? |
|
The problem is as soon as the container/openHAB is restarted and a device cannot be reached during this time. I can no longer see the time of the last seen. I haven't noticed this behavior in the past, it only came with an update. Unfortunately I can't say since which version. After restarting the openHAB system (Docker container on Raspberry Pi 5), the "lastseen" items from the Network Binding are overwritten with UNDEF if the devices are not reachable at the time of restart. |
The behavior is clear, should have stated that. Was mainly interested in the use case. Personally i don't care that a device's lastseen state is set to UNDEF until it reachable again. My openHAB rarely reboots (maybe 2 times a year), no automations are affected and i don;t see a purpose to look at these values at all, it will get updated evantually. A simple woraround could be to add a rule that whenever a command is received with the UNDEF state you can issue a postUpdate with the last state from persistence. |
|
So my system starts up more often. During host updates, openHAB update, monthly backup, RSYNC jobs... I've had a rule that sets the value automatically for a long time, but I don't think it's a clean solution. I actually think that the binding should take over this work again ;) Thank you. |
Description:
After restarting the openHAB system (Docker container on Raspberry Pi 5), the "lastseen" items from the Network Binding are overwritten with UNDEF if the devices are not reachable at the time of restart. The items are initially loaded correctly from the MapDB and displayed, but subsequently, the timestamp is set to UNDEF if the devices are not reachable during the restart. Once the devices are back online and reachable, the timestamp updates normally. This behavior occurs in both Bridge-Mode and Macvlan-Mode and has been observed since the update to openHAB 4.2.1.
Expected Behavior:
Before Restart: The timestamp of items showing device availability is correct.
After Restart: If the devices are not reachable at the time of restart, the items are correctly loaded from the MapDB, but then the timestamp is set to UNDEF.
After Devices Are Reachable: The timestamp updates as expected, but the UNDEF value persists until the next update.
Log Examples:
Example 1:
Example 2:
System Environment:
openHAB Version: 4.2.1
Docker Version: 20.10.24+dfsg1, build 297e128
Raspberry Pi Model: 5 (8GB)
Operating System: Raspberry Pi OS
Raspberry Pi 5 Model B Rev 1.0
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
Linux raspxx 6.6.47-v8-16k+ #1792 SMP PREEMPT Thu Aug 22 15:13:10 BST 2024 aarch64 GNU/Linux
Network Configuration: Tested in Bridge-Mode and Macvlan-Mode
Additional Tests:
A test system with Network Binding and MapDB shows the same behavior. Switching from Pi4 to Pi5 did not resolve the issue.
Troubleshooting:
Container Restarts: The issue persists regardless of the restart method (manual or during backup jobs).
Update to openHAB 4.2.1: I think, the problem started after this update.
Regards, Lenschi
The text was updated successfully, but these errors were encountered: