Home AMX General Discussion

Philips Pronto Module Example

amdpoweramdpower Junior MemberPosts: 110
Hi guys. I took some of the examples and info I found on the forums and started digging into the Philips Pronto TSU9400. I've started writing a pretty advanced module with the goal of having a reusable ProntoScript and Module that can (as closely as possible) mimic an AMX touchpanel in both coding and functionality. Right now, it supports feedback, separate button pushes and releases, simple levels and I've fooled around a bit with dynamic images. My main concern is that the connection gets dropped with inactivity and I haven't found a good way in Prontoscript to reinit the connection when it is dropped. What I've tried doesn't seem to work. This example zip file is a mess right now as it is a work in progress but should give a good start if you are familiar with the device. Basically, all that is needed is adding the script to each device and then going to the "Advanced" tab of a button and entering something such as "[email protected]". This would be Port 2, Channel 3 on the NI Master. Again, my main problem is maintaining the IP connection. If anyone could help out, it would be great. Any comments are welcome.

Comments

  • Jeff LockyearJeff Lockyear Junior Member Posts: 147
    I downloaded your module and gave it a try. Thanks for getting me started! The only thing I can't sort out is button feedback on the Pronto. If I send ON [vdvPronto2,105] for example, I get an *ACK* but the button doesn't change state.

    I don't have any Java experience (I came to Netlinx via Landmark, albeit a long time ago) so any light you could shed on why I might be having this problem would be much appreciated.

    Jeff
  • amdpoweramdpower Junior Member Posts: 110
    Yeah, the button feedback is a bit of a kludge at the moment. I basically does an image swap on the Pronto. Since the stupid Pronto doesn't save page states, I need to request button states on the page whenever it is loaded. I think I figured out real time states as well but I can't remember. I'm going to be diving back into this when I have some time. I'll let you where it stands.
  • xrmichaelxrmichael Junior Member Posts: 79
    Pronto

    You could use the pronto 'global var', or combine all pages under 1 activity, that is the way i will go with it i reckon
  • xrmichaelxrmichael Junior Member Posts: 79
    Pronto

    I got the channels working on this now, drop me a line if you want the code.
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    Here's mine.

    Supports standard AMX commands of @TXT, @SHO, @PPN, & @PPF.

    Popup's are in an include file, since the pronto doesn't support grouping commands. Basically you have to setup which buttons are in a particular popup and it does a series of @SHO's for you.

    Full reconnection is supported. This module has been in the field for a couple of jobs and has been working fine. You need to have at least firmware 5.06 on the pronto and a duet master (non-duet master's handle IP connections a little different).

    Commands are sent to the virtual, pushes/releases are received from the virtual. It's a timed_do_push so the hold event works fine.

    Should be easy to follow, but the reconnection is a little odd due to the quirkiness of the pronto. With firmware 5.06, the pronto has three states: awake, resting, and asleep. Awake is no problem, asleep is no problem. Resting the pronto will run a few scheldule_after events once a minute. It quits listening before AMX can send all updates though.

    The pronto sends out a series of heartbeats when it's awake. Once the heartbeat count hits three, it's cool for AMX to send updates. Upon initial connection, heartbeat is immediately set to 3 so all pending updates go out. As long as the pronto is being used, the heartbeat stays at three and all updates go out. When it goes into rest mode, the heartbeat will only get up to 2 and pending updates will get queued. The buffer is pretty big, but SHO's & PPF's get priority (don't want to leave an unneeded button hanging up). I would suggest adding a close button to any pop-up's, just in case they do miss the close.

    Of course when the remote does go to sleep, the connection fails and the IP device goes off-line. Pick the remote up and it re-connects making the IP device go on-line. So just quit sending stuff when offline, refresh when it comes online.

    I did make use of global variables to hold variable text common to all pages. The page pronto-script updates before the page is drawn, but the device pronto-script doesn't run until after the page is drawn. So if you use multiple pronto device pages like I did, the common text will stay the same from page to page (updated on initial connection and online event, save to a global variable, and then loading from global on every other page).

    Feel free to copy the re-init code from mine. It's mostly made up from other pronto-script modules anyway.

    Kevin D.
  • elytronicelytronic Junior Member Posts: 51
    This thread is very interesting for me.

    Now that we can make the little prontos communicate with AMX 2-way is there any reason to spec the R4 that is twice the price, requires a different network infrastructure and has a tiny screen?
  • iainshawiainshaw Junior Member Posts: 133
    R4

    And is soooooooo slow. Not specced an R4 since we got our demo model - that's a pretty bad indictment and in that time we've sold lots of RTI T2Cs.
  • elytronicelytronic Junior Member Posts: 51
    elytronic wrote: »
    This thread is very interesting for me.

    Now that we can make the little prontos communicate with AMX 2-way is there any reason to spec the R4 that is twice the price, requires a different network infrastructure and has a tiny screen?

    what others think about my statement above?
  • amdpoweramdpower Junior Member Posts: 110
    Kevin,
    Thanks so much! I haven't visited this in a while but you can bet I will be now! Can't wait to give it a go. On the R4... It was a huge disappointment for me. I was so excited to use one and when I got the opportunity, I never went back. The communication has been improved but Zigbee is limited and doesn't appear to be a good choice for communications. The Pronto is very cool and with the dock, battery is not a problem. I wish the screen was a little better on the 9400 but other than that, I think it's a much better choice given a reliable module. Which I hopefully have now! Thank again.

    Jack K.
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    I'm really bad about comments (IE, probably none), so if you have any questions let me know. The caller ID pop-up is left in just for demo purposes. I found it easier to group all the pop-up buttons on the pronto together after you have the pop-up setup, so you can move it out of the way (or delete, copy/paste from another page) to work on the normal page below. Kind of a pain since you have to have all buttons on the screen you will ever use.

    My Prontoscript is really bad and I'm sure I have way too many catch (e)'s and finally's. It was easier to force a reconnect on any error then work out what caused them.. ;) Also, pop-up's were the last thing I added and I couldn't get the FOR loop working right to hide all the pop-up buttons on initializing (hence the 10 or so hide button lines on the bottom). Initial plan was to have pop-up button start/stop settings on the parameter page, and just FOR loop start to stop hiding them. Another one of those round tuit's..

    Kevin D.
  • amdpoweramdpower Junior Member Posts: 110
    Kevin,

    Thanks again. I've got the reinit/stay alive stuff working in my project now. However, I'm trying to wrap my head around how the hell this thing handles connections. At first I thought the the Heartbeat was just to notify the AMX. However, am I correct in thinking that this is needed to keep the connection "Semi-Alive"? It's like the remote checks to see if some runtime code is active after "inactivity" of user interaction and then decides to only check in once a minute. If nothing is going on then it quits. If something is going on, then it executes twice and sleeps for another minute? Is that right? If so, that is flat out goofy!

    Jack K.
  • amdpoweramdpower Junior Member Posts: 110
    Hmm.... That didn't quite work. I still have the same problem. Resting is no problem. However, when the remote goes to "asleep", moving the remote wakes it up but it doesn't reconnect. What am I missing?
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    You need to have a newer version of the Duet firmware and the Pronto needs to be at least version 5.06. Have you tried running the only module as is, without any additional code?

    Essentially the heartbeat command gets sent every two seconds. When the pronto screen goes off it only runs the script once a minute(just the way it is). When it does it will get one or two heartbeats out( but sometimes three), hence the need for four beats within a set period of time for AMX to know it's fully awake and to send out everything it's queued up.

    It shuts back down before AMX can send much of anything (only about 4 commands, the sleepy_send wait is what limits the outgoing messages to 4 when the remote is sleepy)

    This heartbeats every minute also help keep the connection alive. Eventually the remote goes fully to sleep and the connection is lost.

    Since the heartbeat goes out every two seconds, when you wake the remote back up it will try to send out a heartbeat command a maximum of two seconds later (usually a lot quicker). Since the connection is dead, this throws an error. The Catch(e)'s and finally's then destroy the socket, recreate it, and reconnect. It's queuing up commands being sent, so you shouldn't lose any commands. The reconnection it pretty quick so there's barely any lag from when it's fully asleep.

    Kevin D.
  • amdpoweramdpower Junior Member Posts: 110
    Actually, I incorporated your reinit code with what I had. I do have the latest duet firmware and 5.06 Pronto. I probably screwed something up somewhere. I think another function I had in there tried to make the connection along with the heartbeat function which probably caused a conflict. I just caught the mistake it but I'm away from the unit right now so I'll give it a go when I'm back at home. Thanks.
  • amdpoweramdpower Junior Member Posts: 110
    Interesting. There's a new firmware posted on the site 6.0.21. Read the comment. I just upgraded and noticed that I'm over 30 minutes into the remote sitting off of the charger and it is still sending the heartbeat every minute. I previously had 5.0.6. I'm wondering if this new release prevents the unit from fully going to sleep.
    http://www.pronto.philips.com/index.cfm?id=1533

    What's new in TSU9400 firmware v.6.0.21
    This release fixes a problem where in some rare cases the connectivity is lost after several days of use.
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    Didn't make a difference on my end. 5.x or 6.x work the same with the module.

    Kevin D.
  • RicardoSiqueiraRicardoSiqueira Junior Member Posts: 373
    Kevin,

    Thanks for sharing your module with us. I am thinking about implementing it on a job where the clients will have 3 or 4 AMX touch panels and probably 7 or 8 Prontos (TSU9400). My question is what do you do when you have multiple Prontos and Wireless Access Points? In my case, I will have 3 Access Points with the same SSID. Is there a problem with the Prontos trying to connect with the distant APs or roaming bugs? I will have just 1 NI4100, so how do you setup the multiple Prontos so they work independently? Do you have a separated port (svPORT1) for each Pronto besides the Virtual devices declaration? (svPORT1 = 81, svPORT2 = 82, etc). How reliable are your projects with the Wi-Fi Prontos?

    Thanks,

    Ricardo
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    Kevin,

    Thanks for sharing your module with us. I am thinking about implementing it on a job where the clients will have 3 or 4 AMX touch panels and probably 7 or 8 Prontos (TSU9400). My question is what do you do when you have multiple Prontos and Wireless Access Points? In my case, I will have 3 Access Points with the same SSID. Is there a problem with the Prontos trying to connect with the distant APs or roaming bugs?

    The pronto's will eventually jump to the new access point. It takes about a minute to disconnect and renegotiate. On the prontoscript section of Phillip's website, they have a small chunk of code that will check the connection and disconnect/reconnect as needed.
    I will have just 1 NI4100, so how do you setup the multiple Prontos so they work independently? Do you have a separated port (svPORT1) for each Pronto besides the Virtual devices declaration? (svPORT1 = 81, svPORT2 = 82, etc).

    Yup, multiple modules with different ports and virtual's.
    How reliable are your projects with the Wi-Fi Prontos?

    Thanks,

    Ricardo

    About as reliable as the pronto's themselves. Meaning they will lock up or quit communicating over IP every once and a while. They do that without running prontoscript and just using the Phillips extenders as well. A reset or on/off gets it back. No complaints from any customers yet!

    Kevin D.
  • RicardoSiqueiraRicardoSiqueira Junior Member Posts: 373
    Kevin,

    Thanks for the info and for answering my questions. Regarding the multiple Access Points, since we will be using Cisco APs, I can set different SSIDs on them to limit the Prontos to connect only to the closest APs. Thanks,

    Ricardo
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    If the remotes don't need to roam, that would work perfect.

    Kevin D.
  • RicardoSiqueiraRicardoSiqueira Junior Member Posts: 373
    Kevin,

    I setup a test project in my office with your Pronto/AMX Wi-Fi solution and it works great. However, since I will be deploying this solution in a project with 9 Prontos and 1 NI-4100, I have one more question: Will I have command loss or conflicts when I have multiple Prontos being used at the same time? Or the NI-4100 will buffer the multiple commands coming from different Prontos to prevent the command/button push loss? I am assuming that the TSU9400s will work similar to a regular AMX touch panel, is this correct? If so, we should have minimal or almost no conflict, right? Please let me know your thoughts and thanks again for sharing this solution with us.

    Ricardo
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    Each module will be separate and they won't interfere at all. Some things to remember that I have forgot at one point or another:

    Make sure all pronto's have a different IP address
    Make sure all have a different port (in the pronto file and AMX)

    Max I've done is 3 in one house, but each one has it's own TCP/IP path so no conflict should ever come up.

    Kevin D.
  • duhaduha Junior Member Posts: 1
    Hi,

    Maybe there is a new version of this code?
    How can we sent data from AMX to Pronto every 2 seconds, like the answer on a Beat? When I change Volume on another Philips panel, I want to see this just immediately on another panel.

    Sorry for my English, I'm from Russia :)
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    That would be handled just like you would any native AMX panel. Send a variable text update to all the prontos when the volume level changes. If a pronto is asleep when it happens, it will update when it wakes back up.

    Kevin D.
  • WESLEY.CHRISTELISWESLEY.CHRISTELIS Junior Member Posts: 1
    How do I get the button feedback going on this Module, I am a little new at this, ca
    shr00m-dew wrote: »
    Here's mine.

    How do I get the button feedback going on this Module, I am a little new at this, can I sue LEVELs as well
    ===================================
  • shr00m-dewshr00m-dew Junior Member Posts: 394
    Never got around to button feedback as Philips killed the TSU9xxx off and we quit selling them. It would be a pain to do, but doable.

    No levels as well either.

    Kevin D.
Sign In or Register to comment.