Home AMX User Forum AMX Control Products

Determine a UI reboot in code

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.

Comments

  • jjamesjjames Posts: 2,908
    Well - the panels don't actually reboot anymore, they reload the file. What you *could* do is brush up on ICSP and watch for a transfer command going to any of panels and set a flag. You can monitor ICSP internally by using the "icspmon" command via telnet.

    I could write a module that does this if you're interested . . . for the low-low price of a new NI-3100. ;)
  • John NagyJohn Nagy Posts: 1,734
    You might do what we are doing:
    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.
  • viningvining Posts: 4,368
    jjames wrote: »
    Well - the panels don't actually reboot anymore, they reload the file. What you *could* do is brush up on ICSP and watch for a transfer command going to any of panels and set a flag. You can monitor ICSP internally by using the "icspmon" command via telnet.

    I could write a module that does this if you're interested . . . for the low-low price of a new NI-3100. ;)
    That may be more taxing on the system that just refreshing once when going on a dev's page after an offline/online event.

    John Nagy wrote
    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.
    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.
  • viningvining Posts: 4,368
    The method that JN suggested works very well once you figure out what a custom event is all about. It's still very easy to impliment and it takes just a couple of minutes to figure once you realize you need a custom event. I'm a little slow and initially skipped over the part that mentioned custom event when reading up on the "?TXT" TP command. Initally I thought I could just get the returned string in the UI data event string handler, duh! You need "CUSTOM EVENT" to catch the returns of button queries. Again it's real easy.

    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. :D
  • John NagyJohn Nagy Posts: 1,734
    I'll take all the thumbs I can get!

    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...
  • jjamesjjames Posts: 2,908
    I'll actually give that two thumbs up too, but they go to the programmer - not the marketer. ;)
  • John NagyJohn Nagy Posts: 1,734
    Thanks, it was indeed my idea.
    Motivated by the desire to achieve, not by the desire to beat others.
  • jjamesjjames Posts: 2,908
    Well then you deserve the thumbs up, which I'll gladly give. :)

    Not quite sure of the irony here - but okay.
  • viningvining Posts: 4,368
    What's the trick to making R4s respond to the btn query when they come online? I send the COMMAND string ?TXT-VT_ADDR,1 but the R4s don't respond while my TPs do. According to PI they support the command so wazzz up?

    R4
    Line     81 (17:38:30)::  UI DEBUG (1): DATA_EVENT: UI INDEX-[ 12 ], IS NOW ONLINE :DEBUG<1356>
    Line     82 (17:38:30)::  UI DEBUG (1): UI DEVICE-[ 10025:1:0 ], DEVICE_ID-[ 322 ] :DEBUG<1363>
    Line     83 (17:38:30)::  UI DEBUG (1): UI DEVICE-[ 10025:1:0 ], IS-[ R4 Remote ], TYPE-[ 6 ] :DEBUG<1503>
    Line     86 (17:38:30)::  UI DEBUG (1): DATA_EVENT: UI INDEX-[ 12 ], IS NOW ONLINE :DEBUG<1514>
    Line     87 (17:38:30)::  UI DEBUG (1): DATA_EVENT: UI INDEX-[ 12 ], SENDING BTN TXT QUERY :DEBUG<1515>
    

    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)
    Line     39 (17:44:02)::  UI DEBUG (1): DATA_EVENT: UI INDEX-[ 1 ], IS NOW ONLINE :DEBUG<1356>
    Line     40 (17:44:02)::  UI DEBUG (1): UI DEVICE-[ 10001:1:0 ], DEVICE_ID-[ 343 ] :DEBUG<1363>
    Line     41 (17:44:02)::  UI DEBUG (1): UI DEVICE-[ 10001:1:0 ], IS-[ G4 Panel ], TYPE-[ 7 ] :DEBUG<1503>
    Line     72 (17:44:02)::  UI DEBUG (1): DATA_EVENT: UI INDEX-[ 1 ], SENDING BTN TXT QUERY :DEBUG<1515>
    Line     77 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], RX BTN TEXT-[ R ] :DEBUG<2948>
    Line     78 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], SENDING CMD, SET BTN TEXT TO "I" :DEBUG<2950>
    Line     79 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], SETTING UI_BOOT ARRAY AND RUNNING BOOT TASKS :DEBUG<2953>
    Line    101 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], CONFIRMING BTN TEXT SET TO "I" :DEBUG<2960>
    Line    104 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], RX BTN TEXT-[ I ] :DEBUG<2973>
    Line    105 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], REBOOT / INIT BTN HAS BEEN SET TO "I" :DEBUG<2974>
    Line    106 (17:44:06)::  UI DEBUG (1): CUSTOM_EVENT: UI INDEX-[ 1 ], INDIVIDUAL DEVs STILL NEED TO BE INITIALIZED :DEBUG<2975>
    
  • a_riot42a_riot42 Posts: 1,624
    I don't understand the need for this. When a UI comes online I update it with all the information it would need to be correct generally just zone, source, and volume and perhaps a few other tidbits like projector power status. Unless you are actually building the graphics for the panel when it comes online, I would think that it makes sense to send all updates when it comes online, at least for whatever page the user is on. There is no sense in doing updates for pages the user can't see until they flip to them. How many commands are you sending when a panel comes online? I think I max out at between 5-10, and then more depending on the source they are currently watching if the system is not off.
    Paul
  • viningvining Posts: 4,368
    a_riot42 wrote: »
    I don't understand the need for this. When a UI comes online I update it with all the information it would need to be correct generally just zone, source, and volume and perhaps a few other tidbits like projector power status. Unless you are actually building the graphics for the panel when it comes online, I would think that it makes sense to send all updates when it comes online, at least for whatever page the user is on. There is no sense in doing updates for pages the user can't see until they flip to them. How many commands are you sending when a panel comes online? I think I max out at between 5-10, and then more depending on the source they are currently watching if the system is not off.
    Paul
    Well in my case which I'm sure isn't as complicated as what JN's guys do I have alot of things that only need to be updated after a reboot. Things such VT that is basically static in nature but populated through code. Zone names and other things which never change except through hard coding and a subsequent file transfer. Presently I have to send these to the panels when the panels come online or every time I go to that page but It's only really necassary once after the panel is rebooted, not every time it comes online for reasons other than a reboot or every time I go onto a specific page. Of course there is other feedback that is dynamic in nature that needs to be updated when ever the TP comes online or when it goes to a specific page and that is dealt with differently.

    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.
  • John NagyJohn Nagy Posts: 1,734
    We don't ask the R4's if they are current because we already severely limit traffic to them already. So we haven't tried to get this trick to work with them yet. I'll see what engineering says about it.

    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.
  • a_riot42a_riot42 Posts: 1,624
    John Nagy wrote: »
    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

    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
  • John NagyJohn Nagy Posts: 1,734
    You made the point, that's too many commands for every online event, that's why we developed a way to reduce it.

    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.
  • a_riot42a_riot42 Posts: 1,624
    To my way of thinking, that's far too much choice for a client. You can paralyze someone with that much choice, and to me at least, my job is to reduce cognitive load, not increase it. I don't want my customers "thinking" when they use my UI. In fact the biggest compliment a client can give me if I ask them about the UI, is "Um, I think its fine, I haven't really thought too much about it...". Then I know the UI is staying out of the way to the point where they aren't even making a judgement about it. I think that the customer is paying me to provide them an interface that works well without needing a lot of thought.

    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
  • John NagyJohn Nagy Posts: 1,734
    You've misread the purpose and execution. Because the system allows changing things in so many ways FROM THE PANELS, a dealer can set it up any way the customer requires for the job and their desired simplicity or complexity (or both or any variant for different users), then lock it down or any parts of it down, all without having to re-author the panels or adjust the code. Same for when the customer wants small or large changes... no new code, no new panel work. Thus one system design can be any system design you want, not implying that it will change from minute to minute. Although for such things as favorite channels, and a few others, it indeed can, and our customers use it. They especially like that it doesn't cost them another $400 if they want to change a favorite, and everybody gets their own favorites.

    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.
  • PhreaKPhreaK Posts: 966
    a_riot42 wrote: »
    ...my job is to reduce cognitive load, not increase it.
    Every AMX programmer should chant this three times before starting work each day. And again at Lunch.
  • John NagyJohn Nagy Posts: 1,734
    +1 on that.
Sign In or Register to comment.