R4 tips and tricks
BCalderwood
Posts: 35
I'm starting this thread in hopes that any information gathered here will help others when coding for the new R4 remotes that have recently came out. I'm hoping, as I know some of you are, that AMX will fix some of the bug issues that I have seen on this forum about the R4 remote and the Zigbee gateway/repeaters. Until then, I think that it is up to us to make these things work like they should so I have taken the liberty of compiling a few here.
Here is a short list of a couple of items that I have found, either in this forum or in my personal experience. Please feel free to add to this as you seem fit as that is the point of this thread.
1. The sleep timer issue. There seems to be an issue of when the R4 goes offline when it goes to sleep, it has a problem coming back online. There was a suggestion from another thread to disable the sleep function through the set up menu and code one in yourself. There was another great hint to use the uncombine/combine keywords in the offline/online events between the virtual and physical R4 device to better control the way data is handled and when sent to the physical device. Obviously, you will have to have page tracking enabled and parse the strings coming from the R4 in regards to the current page that the R4 is on. This leads into number 2 below.
2. Page tracking. Turn on page tracking in the R4 remote and send feedback to the device only when needed. This seems to be due to the bandwidth on the zigbee network. It helps to make sure that info is only sent to the R4 when absolutely needed, therefore keeping network traffic to a minimum. Now, this may seem a bit excessive, but don't run your feedback in mainline for the R4. Use the button event or some other event to send your feedback. In mainline, I am assuming that some network traffic is created just making sure that buttons are on or off based on whatever you base your feedback on. I'm going to try and see if page refreshes can work if you need to update feedback for the R4. I haven't looked into this yet but any suggestions will be appreciated if I'm barking at the wrong bush.
3. Keeping the zigbee gateway location away from the wireless gateway location. There was a thread mentioning that locating the two gateways in very close proximity to one another can cause some reliability issues with one or the other networks. I'm not sure if this was a one time problem or not but hey, every little bit helps, right? It was mentioned to try and keep the channel of the wireless network low and the zigbee channel high or something to that effect to further seperate them I believe.
4. When sending text commands to the R4, try to send them with somewhere around .5 seconds between commands if you are populating a large amount of data on an R4. Technote 823 goes into more detail then I am going into here so if you haven't read it, I highly recommend it before you start coding for an R4. Better yet, populate your data before sending the page flip. Either way, you have to wait. I don't know if this is the best way to do it but if anyone has a better suggestion, please add.
5. Another thread stated that when you are downloading your file updates via USB into the R4, you can save some time from 3 reboots to 2 reboots for an update. Change your setting from mesh to usb, reboot, change from usb to mesh without rebooting, download your file update which will then reboot the R4 for you when done.
6. Now, this is my own suggestion and makes sense from a network bandwidth point of view. If you have page tracking on, you will receive strings to your master whenever you flip a page letting you know what page is active. But don't send page flip commands to the R4 everytime you need to flip a page or send a pop-up. Let the TP4 file do it for you. That way you are cutting back on some of the data being sent to the R4. If you have page tracking on, you'll receive a command anyways letting you send feedback, text commands etc. only when needed as stated in #2 above.
7. It seems that when you are using the zigbee repeaters, you will have half the bandwidth available than if you are using the gateway alone. Now that's a problem because you now have more devices for half the network bandwidth. So being very careful to send data only when needed is even more important.
8. I have seen a few mentions in this forum that the R4 is really good for small systems and would be harder to implement for larger systems. I simply refuse to accept this so I'm going to make the ones I have work flawlessly in larger systems or break 'em. Whichever comes first. I do believe that you can have several of these working in a large system as long as you are very careful about your usage of data sends and receives. Audio/Video Requests send a large amount of data and I am using one each of these with a Sirius tuner, text feedback for status and pretty buttons that light up whenever. Then I will add more R4's to see if they still work as well or I will have to start cutting back on things until they do. I'll keep this post alive with my experiences as I experience them.
9. Volume ramps. Use a timeline or waits to stop your volume ramp on an R4 or any Modero for that matter. Don't rely on the release event to stop your timeline. TIMELINE_KILL in the offline event will help in the case of a problem as well as your release. Or don't use the release at all. Use the push on a button event to reset your timeline since some people can sometimes hit it twice. Either way, have something to stop the ramp just in case. Someone in this forum mentioned to pulse a volume increment/decrement on the release of a button event. When I did Landmark systems (back in the day), I use to do all of the coding on the button release section so depending how you code your volumes, seems like a good idea to me.
I could go on from here but these are a few to start off with and once again, I highly recommend reading TN 823 and TN 818 before you start coding for your new R4 remote. It was very helpful for me anyways.
If anyone else would like to add or subtract to this list based on your experiences, please feel free to do so. That way, until AMX fixes some of these issues or does not, we at least have a running list of suggestions to help those that are having problems. Now, I'm going to finish implementing some of these as I have 10+ R4's to get ready to program for so good luck and thanks to all of you that have submitted your suggestions in this forum which helped me to start this thread.
Here is a short list of a couple of items that I have found, either in this forum or in my personal experience. Please feel free to add to this as you seem fit as that is the point of this thread.
1. The sleep timer issue. There seems to be an issue of when the R4 goes offline when it goes to sleep, it has a problem coming back online. There was a suggestion from another thread to disable the sleep function through the set up menu and code one in yourself. There was another great hint to use the uncombine/combine keywords in the offline/online events between the virtual and physical R4 device to better control the way data is handled and when sent to the physical device. Obviously, you will have to have page tracking enabled and parse the strings coming from the R4 in regards to the current page that the R4 is on. This leads into number 2 below.
2. Page tracking. Turn on page tracking in the R4 remote and send feedback to the device only when needed. This seems to be due to the bandwidth on the zigbee network. It helps to make sure that info is only sent to the R4 when absolutely needed, therefore keeping network traffic to a minimum. Now, this may seem a bit excessive, but don't run your feedback in mainline for the R4. Use the button event or some other event to send your feedback. In mainline, I am assuming that some network traffic is created just making sure that buttons are on or off based on whatever you base your feedback on. I'm going to try and see if page refreshes can work if you need to update feedback for the R4. I haven't looked into this yet but any suggestions will be appreciated if I'm barking at the wrong bush.
3. Keeping the zigbee gateway location away from the wireless gateway location. There was a thread mentioning that locating the two gateways in very close proximity to one another can cause some reliability issues with one or the other networks. I'm not sure if this was a one time problem or not but hey, every little bit helps, right? It was mentioned to try and keep the channel of the wireless network low and the zigbee channel high or something to that effect to further seperate them I believe.
4. When sending text commands to the R4, try to send them with somewhere around .5 seconds between commands if you are populating a large amount of data on an R4. Technote 823 goes into more detail then I am going into here so if you haven't read it, I highly recommend it before you start coding for an R4. Better yet, populate your data before sending the page flip. Either way, you have to wait. I don't know if this is the best way to do it but if anyone has a better suggestion, please add.
5. Another thread stated that when you are downloading your file updates via USB into the R4, you can save some time from 3 reboots to 2 reboots for an update. Change your setting from mesh to usb, reboot, change from usb to mesh without rebooting, download your file update which will then reboot the R4 for you when done.
6. Now, this is my own suggestion and makes sense from a network bandwidth point of view. If you have page tracking on, you will receive strings to your master whenever you flip a page letting you know what page is active. But don't send page flip commands to the R4 everytime you need to flip a page or send a pop-up. Let the TP4 file do it for you. That way you are cutting back on some of the data being sent to the R4. If you have page tracking on, you'll receive a command anyways letting you send feedback, text commands etc. only when needed as stated in #2 above.
7. It seems that when you are using the zigbee repeaters, you will have half the bandwidth available than if you are using the gateway alone. Now that's a problem because you now have more devices for half the network bandwidth. So being very careful to send data only when needed is even more important.
8. I have seen a few mentions in this forum that the R4 is really good for small systems and would be harder to implement for larger systems. I simply refuse to accept this so I'm going to make the ones I have work flawlessly in larger systems or break 'em. Whichever comes first. I do believe that you can have several of these working in a large system as long as you are very careful about your usage of data sends and receives. Audio/Video Requests send a large amount of data and I am using one each of these with a Sirius tuner, text feedback for status and pretty buttons that light up whenever. Then I will add more R4's to see if they still work as well or I will have to start cutting back on things until they do. I'll keep this post alive with my experiences as I experience them.
9. Volume ramps. Use a timeline or waits to stop your volume ramp on an R4 or any Modero for that matter. Don't rely on the release event to stop your timeline. TIMELINE_KILL in the offline event will help in the case of a problem as well as your release. Or don't use the release at all. Use the push on a button event to reset your timeline since some people can sometimes hit it twice. Either way, have something to stop the ramp just in case. Someone in this forum mentioned to pulse a volume increment/decrement on the release of a button event. When I did Landmark systems (back in the day), I use to do all of the coding on the button release section so depending how you code your volumes, seems like a good idea to me.
I could go on from here but these are a few to start off with and once again, I highly recommend reading TN 823 and TN 818 before you start coding for your new R4 remote. It was very helpful for me anyways.
If anyone else would like to add or subtract to this list based on your experiences, please feel free to do so. That way, until AMX fixes some of these issues or does not, we at least have a running list of suggestions to help those that are having problems. Now, I'm going to finish implementing some of these as I have 10+ R4's to get ready to program for so good luck and thanks to all of you that have submitted your suggestions in this forum which helped me to start this thread.
0
Comments
However, my guys are on-site today, as r4 zigbee drop out has started to become a problem again.
we are on R4 number two, as the first unit was crashing (dead screen, hi-pitched squeal) after 12 hours or so....
Good probuct for resi, just need to get it solid!
Nice summation.
(by the way, I am the current programmer for AllSmart after you left, the people here are well, hope all is well with you as well.)
I just add making a pop-up page with the mesh button and the reboot button. Then while on-site put an easy button to pop this page up..... saves time of having to enter the setup menus and put in the password.
I am having problems with R4s going from 3 or 4 bars to none. It's not located close to the wifi (Cisco Aironet), but I am going to try putting in a less sophiscated AP tomorrow. I'll let you guys know how it goes.
Ken
ok.. just thinking.. can we set the timeout from Netlinx through a send command??
if so we could do our own timer... so if bedroom is on set timeout to zero... when they hit system.off or after 5 or 10 minutes turn the timeout back to 30
any idea how long you can use an R4 without timeout??
I played around with the timer because I have one remote that is unable to connect to the PAN about once a week. I have to reboot the remote to get it to reconnect.
Have you guys figured out a solution for the connection problems of the remote?
That's a bit of erronious information. Doing that defeats the whole purpose of going over to Zigbee. It does not use part of it's bandwidth in the same way that 802.11 does to create a dedicated link between devices. Doesn't happen.
Consider... 802.15 was developed for sensor networks, to be multipath redundant and self healing... If we had 5 Repeaters all with in range of each other, on my first connection in setting up the mesh, I would drop to 12.5KBps, then to 6.25KBps, then to 3.125KBps, until after all my connections are done, I would be left with a phenomonal (?sp) 1.5625KBps left to play with on my wonderfully redundant but quite crap network.
**EDIT**
NB: The above is used to demonstrate what is NOT the case, that was based on the assumption that it takes part of the bandwidth to create a conenction between repeaters, this is NOT the case, the above is NOT how it works. Sorry for any confusion
I'm still not 100% sure, some places I see 250KBps written and others I see 250Kbps..... trips me out. I will assume small, then I can be pleasantyl surprised when its BIG!!!
Ideally the Gateway (only one permitted) should be central to all repeaters to minimize this leap frogging and reduction in through put. Plus the bandwidth starts at 250KBps, well at least that's my recolection.
I haven't had a chance to play w/ the R4 and ZigBee yet, although I believe I have them in stock for an upcoming install. Like all things RF they do make me nervous especially with a robust 802.11 network in place and of course the Panasonic multi cell which aren't so prevalant in the industrial settings that ZigBee was initially designed for. Plus the industrial sensors are comparably mute when compared to amount of communications we'll want the R4 to handle.
Got my figures crossed.
An image may clear up the example I gave.. I don't think inline images are on though so you will have to go and check it out...
http://stupid.muppetz.com/Mesh.png
Using that as a guide, as it stands at the moment as we haven't been given access to the repeaters, the best we can setup is a Star config, with out R3's and 4's connected directely to the coordinator, our Ethernet Gateway in the AMX world. A slightly bettwe way would be with a Cluster Tree, with our endpoints connected to a repeater (router) which is connected to the Ethernet gateway.
The whole point of Zigbee is to provide us with high redundancy in our network, a MESH. The worst case of a MESH we could have up to 5 hops from device to device, but this is unlikely, and will only slightly affect latency, but not our overall bandwidth. I love the whole idea behind Zigbee, a redundant network, not terrible high data transfer speed, but high reliability. We are really only going to see 5 hops in that example above, if someone puts big sheets of lead between each one of those connections. In reality, the farthest device will take 2 hops to get back to the coordinator and onto the ethernet backbone, but if one, or even 2 devices fail, hell, 3 could fail in that conenction as long as the farthest point could still see one, and that one could see the gateway and the network will still function!
In a word... Awesome. I love it!
I wasn't 100% sure about #7 but I was hoping that others would jump in. Thanks for clearing that up Trav! (Actually, after talking with several people about this, Adding a Zigbee repeater to a gateway does cut the Zigbee bandwidth in half. So, in retrospect, keep that in mind. B - 10-13-07)
Here's an idea that worked in a home using an R4. I put in a DATA_EVENT that whenever an R4 goes offline, (or goes to sleep), I send a reboot command to the Zigbee gateway. Seems to work as a soft reboot since I noticed there was not a lot of time passing before the gateway was back up again. Only a few seconds and it works well. I don't know if it's a great solution but it worked for one home and I'm currently putting it in a second home to see if it works as well. Granted, I admit that it this may not be the best solution but it worked to keep the R4 from losing communication altogether. Before I had entered the reboot function, the R4 was virtually unusable after it went to sleep. Now, it is much more stable. I'm working on Audio and Video Requests data being sent only when needed since the Audio Request data being sent to the R4 was a huge problem and causing general chaos overall with the R4. I'm looking into combining virtual devices through a BUTTON_PUSH on the release event. Then send the data that way but only once and when needed. I'll keep this up to date on my progress.
Ken, I like the idea you had to put a button on the panel to make the set up menu a lot easier to access. I haven't done this yet as I'm already struggling for screen real estate because I'm always trying to put as much as possible in such a tight space. The Moderos are no problem but the R4's are new so I haven't mastered this yet. I did put a connection light on the R4's on every page so I can have a very easy visual to see if it was connected when I wasn't near my laptop.
Brad
P.S. Thx Ken. All is well here and glad to hear that everyone over there is doing good. Take care.
Also, I programmed the code so if the R4 is viewing the Audio Request and it falls to sleep, upon waking the master sends the current data if it doesn't match the R4's wake data. I did this for all the section (music,shade,lights,ect), now it doesn't matter if it falls to sleep.
The transport commands on the playlist page are TINY.
I must be missing something.
Well well well... Seems to me that the R4's that we just received may be a new revision. I haven't checked the revisions of the first ones that we got but the recent ones are revision B3 and they come back online after they go to sleep. That negates the rebooting of the gateway when the R4 goes offline trick that I had to use on the very first ones that we got. I'm glad because it seemed a pain in the arse to have to do that. Oh, and since we are sharing some images of the audio request on an R4, I thought that I'd share mine. Hacked a bit from a module but I think it looks nice.
Ciao!