Home AMX User Forum AMX Control Products

R4 complaints

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.
«13

Comments

  • GSLogicGSLogic Posts: 562
    Every time the R4 comes back online it adds duplicate port data in the online tree - see attached jpg.
  • yuriyuri Posts: 861
    `how is that possible? The R4 remote is like a modero touchpanel right? Same technology, smaller housing... that's what i have been told.
    We have an R4 remote, but i havent had the time to really use it, i'll see what i can come up with :)
  • DHawthorneDHawthorne Posts: 4,584
    Old Landmark devices do the same thing with the device tree. If you change the address, a phantom of the old one will appear as "online" for a while. It seems to be a harmless behavior, if a bit confusing.
  • GSLogicGSLogic Posts: 562
    DHawthorne wrote:
    Old Landmark devices do the same thing with the device tree. If you change the address, a phantom of the old one will appear as "online" for a while. It seems to be a harmless behavior, if a bit confusing.

    After being setup for the first time, the R4 address was never changed. This phantom keep repeating every time the unit comes back online.
  • GSLogicGSLogic Posts: 562
    yuri wrote:
    `how is that possible? The R4 remote is like a modero touchpanel right? Same technology, smaller housing... that's what i have been told.
    We have an R4 remote, but i havent had the time to really use it, i'll see what i can come up with :)

    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.
  • This is what I got from Tech Support:
    We have had a feature request entered several times to allow separate display and radio timeouts. Currently they are the same. This is a battery saving issue and is part of the overall concept behind both Zigbee and the R4. To change this is somewhat out of the design concepts for this device. But, we may find that it is necessary to comply with the requirements of our customers.

    It is possible to set the timeout to Zero. I do not know that this is a particularly good workaround, but is available none the less.
  • GSLogicGSLogic Posts: 562
    The manual states there are different string that can be sent when the unit either goes to SLEEP or OFFLINE. I've tried both and they don't seem to send anything.

    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.
  • Feedback And Sleep

    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.
  • GSLogicGSLogic Posts: 562
    GSLogic wrote:
    The manual states there are different string that can be sent when the unit either goes to SLEEP or OFFLINE. I've tried both and they don't seem to send anything.

    These commands do work in all the other R4s I tried.
  • jjamesjjames Posts: 2,908
    The fact that we must transfer via USB is my biggest complaint. Not only does this mean we can't remotely update these little things, but having to change from MESH to USB settings whenever you update and then test the remote is a bit of a pain.

    Now I haven't actually tested the remote that much, but this disturbs me greatly:
    NOTE (R4 Users): Due to the wireless nature of the ZigBee network, temporary interference (such as leaving a room or large objects passing between the Mio R-4 and its gateway device) may prevent a command from reaching the NetLinx master.
    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.
  • TrikinCurtTrikinCurt Posts: 158
    Doesn't the 8400 come with the same warning for using 802.11? I haven't got too far on the R4 but I swear I had seen that warning before and didn't make too much of it.

    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
  • robswidrobswid Posts: 14
    R4 installed at client

    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.
  • jjamesjjames Posts: 2,908
    Rob - thanks for the update. Do keep us posted.

    Does anyone else have any experience? Good or bad?
  • Spire_JeffSpire_Jeff Posts: 1,917
    wikipedia wrote:
    ZigBee is the name of a specification for a suite of high level communication protocols using small, low-power digital radios based on the IEEE 802.15.4 standard for wireless personal area networks (WPANs). ZigBee, is targeted at RF applications that require a low data rate, long battery life, and secure networking.

    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
  • R4 dropping commands
    TrikinCurt wrote:
    Doesn't the 8400 come with the same warning for using 802.11? I haven't got too far on the R4 but I swear I had seen that warning before and didn't make too much of it.

    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 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.
  • GSLogicGSLogic Posts: 562
    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.
    I've had the same issue on a 8400 with a client walking through his house.
  • 8400 and R4 dropping releases
    GSLogic wrote:
    I've had the same issue on a 8400 with a client walking through his house.

    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.
  • viningvining Posts: 4,368
    It's also important to have the gateway central to the PAN to avoid repeater to repeater leap frogging to access the gateway. I'm not sure if the ZigBee repeaters work the same as LAN repeaters but if it does every repeater reduces your through put by 1/2. Zigbee is also limited a 256k bit rate so it can only do so much then compound that w/ repeater to repeater leap frogging......
  • GSLogicGSLogic Posts: 562
    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.
    I thought the same think, but in my home I can walk in areas with the R4 and the connection is fine, when I try it with my 8400 they fall offline. Yes, the wap and the zigbee are in the same location.
  • GSLogicGSLogic Posts: 562
    Spire_Jeff wrote:
    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
    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.
  • mpullinmpullin Posts: 949
    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.
    What's the solution to this? Put code in the offline event for the device that sets a variable that disables the volume / channel ramping? Would the REPEATING HOLD block run forever in this instance?
  • DHawthorneDHawthorne Posts: 4,584
    mpullin wrote:
    What's the solution to this? Put code in the offline event for the device that sets a variable that disables the volume / channel ramping? Would the REPEATING HOLD block run forever in this instance?

    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.
  • mpullinmpullin Posts: 949
    DHawthorne wrote:
    Of course, someone with one of these could experiment; it may be built in that REPEATs are canceled on an OFFLINE.
    According to Scott's original complaint, they are not.
    DHawthorne wrote:
    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.
    Sounds like a good strategy.
  • GSLogicGSLogic Posts: 562
    DHawthorne wrote:
    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.
  • WAP jams Zigbee
    GSLogic wrote:
    I thought the same think, but in my home I can walk in areas with the R4 and the connection is fine, when I try it with my 8400 they fall offline. Yes, the wap and the zigbee are in the same location.

    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.
  • viningvining Posts: 4,368
    Scott Stanley wrote:
    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
    if if installed correctly and using either ZigBee channel 25 or 26 or a whole amidst the wi-fi channels I wouldn't recommend them is the same location. Not to say I wouldn't put them in the same room, just at opposite ends. Even if you are at different freqs w/in the 2.4 range if they are on top of each other you asking for problems. Give all transmitters/receivers some space.
  • glr-ftiglr-fti Posts: 286
    I received two R4's a couple of weeks ago and was all fired up to start working with them but of course the chargers did not ship yet so I now have 2 R4's with dead batteries. Anyone else have this problem or am I missing some other way to charge these units?
  • GSLogicGSLogic Posts: 562
    vining wrote:
    Scott Stanley wrote:if if installed correctly and using either ZigBee channel 25 or 26 or a whole amidst the wi-fi channels I wouldn't recommend them is the same location. Not to say I wouldn't put them in the same room, just at opposite ends. Even if you are at different freqs w/in the 2.4 range if they are on top of each other you asking for problems. Give all transmitters/receivers some space.
    Just for the record, they are located on different sides of the room.
  • GSLogicGSLogic Posts: 562
    As of now the R4 will only send feedback to buttons 1-255, but I was told a fix is on the way.
  • TrikinCurtTrikinCurt Posts: 158
    The three R4s we have got were kits (with the charging base). I don't think it charges via USB or anything?

    Curt
Sign In or Register to comment.