In this version of the firmware, has the infoChange lifecycle stopped being called every hour as it has been since edge was released almost two years ago?
If not deleted, has the interval been changed?
I’ve been monitoring two drivers for over 3 hours and haven’t seen this infoChanged lifecycle call.
I know that this periodic execution behavior of the infoChanged life cycle has never been included in the documentation.
I was alerted by the fact that some users of devices that had a code to execute in those periodic calls have stopped doing so and are shown offline.
Something has changed as on other occasions, without prior notice.
Now it’s time to deal damage again!
AlejandroPadilla
(Please contact @nayelyz or @Luis_Humberto_Medina )
2
Hi @Mariano_Colmenarejo
the purpose of infoChange was not to be called every hour, it was the result of other processes, using this lifecycle to execute code based on the time it was called may not have been the right approach.
in the documentation, there is an call_on_schedule option that may help you in this case. I’m sorry for the inconvenience, please allow me some time to investigate with the team about this change.
In short, it has been removed. It is what I needed to know to correct or not the code, which is already corrected.
It was precisely using the infochanged lifecycle time interval to initialize a specific non-critical timer with call_on_schedule function, because timers stop under certain circumstances, hub firmware update, driver update, reboot or Hub crash, memory full, . … Taking advantage of this time function saved me the code to automatically initialize the call_on_schedule timer if it stopped for any unforeseen reason.
If we had only used the documented functions in this entire edge process, we would have all gone badly! …
When a function is present from the beginning and for two years, I tend to think that it is something that has a reason to exist and if it is removed, it will possibly be notified.
We still need to verify with the team what happened in this case. What Alejandro mentioned above is what we saw in the previous report when we asked if that was expected.
They mentioned the call to infoChanged was the result of other processes in the backend because it executes whenever there’s a change in the device’s info, and that we shouldn’t rely on the execution of “infoChanged” to any vital functionality.
So, it is unlikely that the change (if there was any) would have been addressed as “stopped calling the lifecycle infoChanged every hour approximately”.
Based on your description we offered a workaround but we still don’t know if this is intentional or not, once we get more info, we’ll let you know.
I know, I was the one that reported in the past the constant execution of the lifecycle, so I remember. What I meant was that we don’t know if it stopped due to a change or if it is actually a bug, so, I don’t want to make any prior conclusions. Sorry for the confusion.
That’s a really poor use/abuse of infoChanged. Relying on anything undocumented like that, what else would you expect when the behaviour was fixed/changed?
hahahaha, I don’t know what you mean by saying this xxx!
Some of us try to help solve the exceptional problems that some users have with some of their devices, using all the resources that the platform has, without affecting the operation of the rest of devices.
And if that method fails or disappears, I try to find another available solution.
In software, as in everything, there are always alternatives, some more beautiful and others not so much.
Did you already know that it would disappear? Or is it that you didn’t even know that this behavior existed?
Maybe it’s less poor and abusive to tell someone who asks you for help to throw it away and buy another one!
I never noticed infoChanged was running periodically. If I had, I wouldn’t have used it to run something else periodically as it wasn’t documented or designed to be used that way.
