Philips Pronto Module Example
amdpower
Posts: 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 "2@3". 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.
0
Comments
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
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
I got the channels working on this now, drop me a line if you want the code.
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.
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?
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.
what others think about my statement above?
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.
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..
Kevin D.
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.
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.
Kevin D.
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
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.
Yup, multiple modules with different ports and virtual's.
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.
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
Kevin D.
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
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.
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
Kevin D.
No levels as well either.
Kevin D.