Determine a UI reboot in code
vining
Posts: 4,368
Is there any way to tell if a UI comes back online as a result of a UI file upload/reboot or just because the wi-fi connection was re-established?
I'm trying to figure the best way to determine if and when a particular dev's UI init commands need to be sent. Stuff like button hide/show or just fix variable text that gets initialized through code when they are flipped to a partuclar page. It's one thing to send these commands first use after a reboot but if the UI came online last because it just woke up or re-established comms with the master again then I shouldn't waste time updating things that aren't needed.
I think it would be nice if the UI's prior to rebooting would notify the master of it's intent to do so and not just drop offline as it would anytime it drops wi-fi with the network. Then I would no why it went offline and be able to update UIs as necassary. Of course that wouldn't be a catch all cuz it could drop wi-fi and then get rebooted so maybe we could query and receive the time a UIs been running (up time) since last boot. Hmmm, I guess I should now check the UI telnet commands and see if we can already do this.
I'm trying to figure the best way to determine if and when a particular dev's UI init commands need to be sent. Stuff like button hide/show or just fix variable text that gets initialized through code when they are flipped to a partuclar page. It's one thing to send these commands first use after a reboot but if the UI came online last because it just woke up or re-established comms with the master again then I shouldn't waste time updating things that aren't needed.
I think it would be nice if the UI's prior to rebooting would notify the master of it's intent to do so and not just drop offline as it would anytime it drops wi-fi with the network. Then I would no why it went offline and be able to update UIs as necassary. Of course that wouldn't be a catch all cuz it could drop wi-fi and then get rebooted so maybe we could query and receive the time a UIs been running (up time) since last boot. Hmmm, I guess I should now check the UI telnet commands and see if we can already do this.
0
Comments
I could write a module that does this if you're interested . . . for the low-low price of a new NI-3100.
The touch panel file has a value as TEXT on a hidden button. That value is set to 0 in the TPD4 file.
Thus, a reload or a reboot sets that value to 0.
When a panel comes online, the code notices and we query the value in that button. If it's 0, we send all the initialization data, and set the value to 1.
Nothing else writes to that value.
So if a panel comes online and we find it has a value 1, we know we can presume it has been initialized and we just update the current information instead of everything (we have a LOT of data driven content on the panels).
We have considered writing a timestamp anytime we do substantial data refreshes and then deciding how old it is on an online query, to decide how deeply to refresh the data. This may be overkill, but worth considering in some circumstances.
John Nagy wrote I like it, that's a perfect solution.
That's similar to some unix methods where they "touch" a file and if it doesn't exists the "touch" creates it and through out the remaining code you just look for the existance of the file and the file is intended to do nothing but exist or not, never written to and never read. A boolean flag to work between langauges since all languages can check to see if the file exists.
Since I'm a PORT per device person I had to create a persistent array nUI_Rebooted[NUM_PORTS_USED][NUM_UIs] so that once a file re-load on a particular UI was determined I could then update my array for each UI/ALL PORT USED so that the next time they went on page I could check this array and only if need be update the fix button text, hide/show and whatever other stuff that only needs to be sent to a UI after a re-load/reboot. Prior to this anytime a UI went on a particular device's page I would update everything. This makes a lot more sense especially when you got alot off data that needs to be sent. I would recommend that everyone do something similar.
John gets two thumbs up for this recommendation.
Reducing panel traffic is key to getting good intercom operation, especially in larger systems (well, "better", does anyone get actual "good" intercom operation in a large - 20plus panel and door - system?). Our systems send a LOT to the panels when they come online, and it has worked just fine for many years (even G3 panels). But we've found that if you keep an INTERCOM panel busy with commands at ONLINE, it appears to interrupt its setting up the intercom readiness, usually resulting in the panel starting over (offline.... online...), whereupon you again flood it with commands... lather, rinse, repeat, and you never, ever finish getting the system running....
We've done a lot of experimenting (with help from AMX) and have moved to using run-time adjustable timelines for delayed data initialization to allow the panels to settle their intercom bits before we tell them ONLY what they missed while they were away. However, this analysis and process creates its own issue - the NetLinx CPU can be overloaded and start dumping processes. So we needed to add a process governor and diagnostics to see what's happening... which adds overhead... lovely. We hope for a higher horsepower NetLinx in the near future...
By the way, this checking-status concept can reduce traffic a lot for iPads, since they come and go all the time and may or may not be starting over clean at any time...
Motivated by the desire to achieve, not by the desire to beat others.
Not quite sure of the irony here - but okay.
R4
The R4 doesn't work through code or control device but I know it's awake since it just came online and accepted page flips (not shown) so why doesn't it respond to ?TXT ?
TP (MVP-9000i)
Paul
I'm basically just seperating FB between stuff that only needs to updated after a reboot (config type stuff) and the everyday normal FB stuff which typically always needs to be updated when I go to a specific page. Even with the FB (config stuff) that's required after a reboot I don't update the device pages until I go to those pages but I only do that the first time I go to a page after a reboot and every subsequent visit to a particular device page just gets the regular updates.
Paul,
With our completely dynamic panels, every project and every room is rendered by data sent at online time. That can be over 1,000 commands in all, as we do dynamic themes, custom channel favorites, option buttons, and lots more. We found that while this was no problem before, INTERCOM panels can't seem to settle their communications quickly after coming online if there's a lot of traffic. So knowing we don't have to send 95% of our start commands to a panel that may have been away only a moment can be a big plus in getting it back in service.
1,000 commands at every online event? Wow, that's a lot of commands. If you have 20 panels coming online, that's 20,000 commands. With iPads going on and offline constantly that would really make for a traffic jam. I can see how a customer might want a custom panel file, but once its set, I can't really see many people changing it around all the time to the point where it needs to be created dynamically at runtime like a webpage. How long does it take for a system to be stable to use after a reboot in a large system with 20-30 panels?
Paul
Warning, what follows answers the question, it's not sales or bragging, it shows the depth of the hole we put ourselves in, happily digging deeper until INTERCOMS slammed a lid on us.
Our system presents a unique face to each user, and yet the touch panel project is exactly the same in every room, every panel, every job. It is dynamically data-driven to present whatever is needed from a large repository of page primitives; touch your name on any panel. touch the room you want to run, and you get the experience you have tuned through your use, as if you never left, even if someone else is using another panel (with an entirely different profile) on the same room. Colors, button appearance, borders, fills, styles, backgrounds, how many of which buttons, what functions the user is entitled to use (and the buttons for those they are not allowed all disappear for simplicity of use). Each user can set their personal choices for all these things and reset them anytime. Even what mix of sources they want fast access to PER ROOM PER USER. And 72 user-set favorite channels PER CHANNEL VENDOR (DTV, CABLE, SIRIUS, etc, as many as 10 vendors per system), and 0ver 100 user-selected option button locations where each user, on each panel, can choose which of over 200 base functions and unlimited custom functions they want to see... and where... and many of those carry feedback such as Lighting states for specific loads, or room temperature for the room you are controlling at the moment, or security, or if the garage is open, or if the fireplace is on, or room monitor buttons that show you what's happening in a room and let you take it over at a touch, or intercoms or phones or... well, there are more than you want to know about. But the panel will need to display a wide diversity of dynamic information and appearance that will have changed while it was offline. And the initial data dump has to be significant. It didn't used to matter; a system with 32 panels would come on line in seconds once the boot was complete. And it didn't really care that we sent all that data; the last panel would be done within 20 - 30 seconds from the first.
Intercoms changed all that. We find that even minimal communication to panels while they are working out their online intercom readiness can cause it to start over.... and never finish. And take the rest of the system down with it.
So yeah, we have worked for the last 6 months to reduce the communications without eliminating function. So it is really valuable to be able to assess what a panel already knows when it comes online... how long it's been gone, and what it really needs to update. Simply painting individual pages "as needed" has not been a useful path, as even one page can have hundreds of data items. Some persistence of data and a way to judge it is required in order to have quick page response... so it is what we do. Because we have to. And it's been a bumpy ride.
I personally would get confused if buttons moved around or changed labels, etc, and I never have clients ask me for that feature. We do the dynamic channel favs, etc, but I've been finding as slick as it is, people tend to watch the same 10 channels so why confuse them with all this needless technology? It might be cool, and fun to get working, but I don't think it helps the client do what they need to do effortlessly, and can confuse novice users, and frustrate experts who want a very snappy system. I've always been a lazy programmer; I only do just enough to accomplish the task and no more, and I am careful to not add needless complexity unless its absolutely required, and even then, I'll usually find a simpler solution that accomplishes almost the same thing. Fortunately this often ends up being just right.
Paul
The overarching point is that "packaged solutions" are desired for ease of deployment, but typically criticized for being inflexible. We've concentrated on both ends of that.