R4 complaints
GSLogic
Posts: 562
I love the idea of the R4 but here is a major issue:
The R4 falls offline every time it goes to sleep (maximum setting of 30 seconds) and there is no way to know if the R4 is sleeping or disconnected.
Trying to keep track of sending data in a large system with many touchpanels is hard enough. The R4 should have two user presets just like all the other touchpanels: one for SLEEP and another for OFFLINE.
The R4 falls offline every time it goes to sleep (maximum setting of 30 seconds) and there is no way to know if the R4 is sleeping or disconnected.
Trying to keep track of sending data in a large system with many touchpanels is hard enough. The R4 should have two user presets just like all the other touchpanels: one for SLEEP and another for OFFLINE.
0
Comments
We have an R4 remote, but i havent had the time to really use it, i'll see what i can come up with
After being setup for the first time, the R4 address was never changed. This phantom keep repeating every time the unit comes back online.
Let me know if your R4 falls OFFLINE every time it goes to sleeps. Maybe there is a setting I missed or there's something wrong with the unit.
If there was just away to turn off the OFFLINE/ONLINE messages, I could work around that.
Such a great concept, I hope AMX finds a way to get this unit working properly with a large system. A small system or a theater room and the R4 would be fine; it only causes trouble when you try to use it in a large system which needs to keep track of all the panels that are online/offline.
Someone may have already posted a fix for the feedback issue.
Simply UNCOMBINE_DEVICES the logical ports from the virtual ports when you get a OFFLINE event. When you get an ONLINE event COMBINE_DEVICES.
The down side of this is that about four seconds elapse from the time R4 comes online until feedback is available.
I tried to work around this by flipping to a logo page when the unit goes to sleep. Problem is that the SLEEP string and OFFLINE are so close together that it only worked about one in ten times.
I disabled sleep timer as someone else mentioned and wrote my own. When sleep_delay elapses it flips to the logo page and then goes to sleep. It is important to notE that if you do a page flip too close to a SLEEP command you will lock up the R4. Only recovery is to remove battery. Be sure to allow time for page flip before sending SLEEP command.
Reset the sleep timer everytime any button is pressed.
BUTTON_EVENT [vdvR4,0]
{
PUSH:
{
CALL 'SLEEP_TIMER'
}
}
I also UNCOMBINE_DEVICES during the sleep routine to keep from having HOLD, REPEAT commands from locking ON.
I know there will be things I have not discovered but right now this solution seems to work around the SLEEP and FEEDBACK issues.
These commands do work in all the other R4s I tried.
Now I haven't actually tested the remote that much, but this disturbs me greatly: Has anyone tested the reliability of the remote? Plus, what is the size of a "large object"? Do you think they mean elephant-large or average-person-large?
Compared to other remotes that we've used the ONLY advantage the R4 has is two-way communication. The remote itself is a great concept, but leaves a lot to be desired and by the looks of it so far needs either quite a bit of tweaking or an R-5 needs to come out that isn't a Zigbee device and uses the probably already available wireless network in the user's home.
Of course I am putting one in my house, so if I am wrong I will be the first to pay for my mistake...
Curt
I have an R4 installed at a client location for 1 week now. Client called to indicate that R4 was offline and not responding. Client pulled battery but no connection. Once client pulled power on gateway unit came back online. Did not get a chance to test this remote for a long time since client was dying for a remote like this. They want 3 more and I can't get them! Time will tell on reliability.
Does anyone else have any experience? Good or bad?
USB only transfer is a restriction caused by using Zigbee. By trading off the ability to send programming via the network, we get better battery life and quick response from off to on states plus a small form factor that fits well in one hand. It is the designer/programmer's job to realize the restrictions caused by this and implement the remote appropriately. The remote is capable of controlling an entire home with feedback being displayed from multiple rooms simultaneously (altho with some network lag), but this doesn't mean that it SHOULD be used as a whole house control in that capacity. This is why there is an MVP-8400. However, putting this remote in a master bedroom with a simplified status of house audio is OFF/ON, goodnight lighting scene activation and security system armed/disarmed would be (IMHO) a very good use of the device. We have to realize that the job of our system (in most cases) is to make the daily operation of the attached systems easier, more convenient, and more reliable. This most of the time requires us as control system professionals to decide when a feature accomplishes this and when a feature is just a bell/whistle that will only cause confusion or frustration for the average user. That all being said, it is a pain to switch between MESH and USB. It would be nice if when a USB connection is detected the Remote automatically switched to USB with 0 timeout.
Sending a lot of variable text to the remote seems slow. This falls under the same benefits/restrictions of zigbee. It just requires that the designer/programmer to understand these limitations and spec the remote accordingly. This also means that good programming practices regarding the sending of feedback are a must. In the end tho, a remote that looks good, is easy to use with one hand (a must for channel surfing), and has the ability to provide the user with realtime status and feedback. I just installed a remote that has realtime radio feedback and I noticed no hesitation as it was scrolling through the stations. Conversely, I setup a remote in the office with all of the functionality of one our standard touchpanels and it crawled through an update of 8-10 buttons on two pages. The update is only sent when you pick the room and then it flips to the page it updated. On the R4, it takes about 4-8 seconds for this to happen.
From my experience with the R4, it does have some limitations, but I feel they are valid compromises. By designing the system with an understanding of it's strong and weak points, it offers us yet one more tool in the toolbox.
Jeff
I have never seen an 8400 loose a command. I have seen the R4 miss a release and leave a hold [2,REPEAT]: running. This is embarassing on a channel UP/DOWN and very serious on a volume command.
All of our work is commercial and we insure as much as is practical that area has good coverage. I am pretty confident 802.11 is more robust than Zigbee.
I could see walking through my house into a deadspot and getting same result with 8400.
Jeff
At $2400 list there better be a very small amount of weak points to this device.
This is the first time that I'm aware that AMX has changed the online/offline/sleep logic of a device. If you are going to design a large comprehensive quality system you have to know which panels/device are online to control the waves of feedback. In my opinion this is the main short coming of the R4.
That raises a good point. To be safe, I would set a flag and run at timeline to ramp volumes, and not use HOLD...REPEAT. Then you could easily kill it if the remote went off line. Of course, someone with one of these could experiment; it may be built in that REPEATs are canceled on an OFFLINE.
I have not seen a problem with the R4 falling offline in the middle of a volume change... yet! but just in case I programmed it up so the volume will only change on a RELEASE. I know you have to push it a couple times to change the volume drastically but it jumps by 2s so it's not that bad.
This is probably a bid duh for everyone but an 802.11 gateway in close proximity to NXR-ZGW will make NXR-ZGW fail.
My wife was dusting and stacked ZGW on top of Linksys gateway. Took me a few minutes to figure out what had happened.
Curt