#1 - R4s falling offline. Some of the time they come back online, but not always.
We have been able to reproduce this, but only in situations with where there is a marginal connection, and/or a large volume of sustained traffic on the network. There is nothing we can do about the falling offline due to traffic/connection, the not coming back is on our bug list.
#2 - They don't always go to there set "Display Timeout", they just stay ON.
There are multiple things wrong with the sleep setup in 3.0.0, only the normal/ideal modes of operation got tested, so a lot of testing here got missed. We are tracking these problems now.
#3 - The WAKE/SLEEP commands do not work (when not in cradle)
There should be an option for the R4 to receive commands all the time... let it think it is in the cradle.
There are 2 separate problems here.
1. When number 2 is fixed, you will have the option to have the remote not sleep(the device will just turn the display off and remain awake) when it is off the cradle, but you will kill your battery life. If you are in the power saving mode(ie sleep), then you CANNOT recieve commands normally. The device is asleep, it is not transmitting or receiving to save power. Any change to how this works will have a significant impact on battery life and thus we cannot see any good reason for making a change in this direction.
2. In 3.0.0, the remote wakeup feature had to be left out for technical reasons. This is where you can use DEVICE_WAKE(device, mode) in the Netlinx code to wake a suspended device. I believe this is currently working in the 5200 panels. As soon as we can get around the technical problems we will try to get this feature in.
We have been able to reproduce this, but only in situations with where there is a marginal connection, and/or a large volume of sustained traffic on the network. There is nothing we can do about the falling offline due to traffic/connection, the not coming back is on our bug list.
I have two remotes on one Gateway and there is no traffic at all when they go offline. This happens 3 to 4 time a day on each remote. I can send you the R4 log if you want.
There are 2 separate problems here.
1. When number 2 is fixed, you will have the option to have the remote not sleep(the device will just turn the display off and remain awake) when it is off the cradle, but you will kill your battery life. If you are in the power saving mode(ie sleep), then you CANNOT recieve commands normally. The device is asleep, it is not transmitting or receiving to save power. Any change to how this works will have a significant impact on battery life and thus we cannot see any good reason for making a change in this direction.
2. In 3.0.0, the remote wakeup feature had to be left out for technical reasons. This is where you can use DEVICE_WAKE(device, mode) in the Netlinx code to wake a suspended device. I believe this is currently working in the 5200 panels. As soon as we can get around the technical problems we will try to get this feature in.
It is good to hear that you will be able to send commands to a display sleeping TP/R4 if desired.
When an R4 is used to control every aspect of a home, updated information is very important.
Think about all the unnecessary updates that will be sent if a remote is set to 10 second display sleep (as in a bedroom.)
What about homes with a large number of remotes being used at the same time? This will actually increase zigbee traffic.
Please feel free to call me as I would love to help. I believe a QUALITY working remote is the key for resi dealers to succeed.
I have two remotes on one Gateway and there is no traffic at all when they go offline. This happens 3 to 4 time a day on each remote. I can send you the R4 log if you want.
It would be a good place to start. Next thing I would look for is.
Have you looked at the diagnostic page(Protected Settings->System Settings->Page 2->ZigBee Diagnostic) on the R4 to make sure the remotes have a good connection?
Are there any intermitant sources of interference(Microwave, Wireless Access Point, etc) close to the gateway or the remote?
It is good to hear that you will be able to send commands to a display sleeping TP/R4 if desired.
When an R4 is used to control every aspect of a home, updated information is very important.
Think about all the unnecessary updates that will be sent if a remote is set to 10 second display sleep (as in a bedroom.)
What about homes with a large number of remotes being used at the same time? This will actually increase zigbee traffic.
Please feel free to call me as I would love to help. I believe a QUALITY working remote is the key for resi dealers to succeed.
If you have enough remotes active at once that capacity is becoming an issue, then you may want to think about zoning the remotes on multiple gateways. Repeaters are great for extending coverage and fixing dead spots, but they do not increase the network's traffic capacity.
Beyond that, you can use in the master to limit the traffic to a single remote. The remote sends messages to the master when it turns the display on and off(the master typically recieves a WAKE or SLEEP message that can be tracked), the master also knows when devices are suspended or not, and you can enable page tracking. You can avoid a lot of network traffic by only updating the currently displayed page on remotes that are awake. Let the master keep track of all the information, and only send the remote what it needs when it needs it. The only remote/page the user cares about being current is the one they are looking at.
You can avoid a lot of network traffic by only updating the currently displayed page on remotes that are awake. Let the master keep track of all the information, and only send the remote what it needs when it needs it. The only remote/page the user cares about being current is the one they are looking at.
I could not agree more and this was a complaint I've had from the start of the R4 wireless design.
Our home system software has been designed to only send data when a TP/R4 is viewing a section (climate/lights/music/etc.) and the section data changes - no new data, no data sent. The way you suggest, data would have to be sent every time a TP(5200)/R4 awake even if the data has not changed, this would increase network traffic. I guess the next step is to first check if it is online and then check if it needs and update.
Tried the install with a R-4; as per instructions.
My R-4 did not work; although it can 'see' the NXR-ZGW' it does not connect to the master (version 3.41.422)
But I can't even 'downgrade' the firmware - using virtual master it errors with:
Transfer Aborted - Uknown NAK Failure Code:0x0012
So my R-4 is dead - what a mess!
I was really M & F'n AMX about this today and of course I didn't check the forums and search for this error number 0x0012 when I first ran into it. I xferred TP files earlier in the week and everything went smooth but today no such luck. Plugged in my base inserted the R4 and I couldn't tranfer, err 0x0012. Remove the USB LAN re-install, several times and no joy. Reboot the R4s, no luck. Closed and re-open TPD4 in between the crashes and no luck. Moved upstairs and xfers OK, hmmm. Back downstairs and try again, no luck. Grab the other R4 that I haven't updated yet, installed in the base and attemp to xfer, no luck. So 3 won't xfer and the one upstairs did so by this point, 4:30 and I killed the main TV set up and I'm M & F'n AMX for another F' up R4 nightmare. Cursed myself a couple of times and asked myself when will I smarten up and stop using these freakin things and finally out of complete frustration caved in and decided to call TS which would be the 5th or 6th time ever. Since I'm over the minimum for free TS I figured maybe they'd be able to help and I can get this set up working again before leaving. Call, entered my ID and got autoferred to sales. Now I'm livid and wanting to smash the f'n remotes since I have tyo talk to sales about my numbers instead of just getting a TS guy to help me with their f'n equipment. Hung up but then decided to call back, talk to sales and ask what the f, I made the quota so where' s my TS but apparently they realized I should have been patched straight thru so they patch thorugh to TS. Told the guy my scenario and the 0x0012 err code and he says, oh that's an error you get when the R4 isn't docked and I'm thinking, can't be, 9 out of 10 times I tried to xfer it was docked and he then asks, did you get the docking pop up and I think, hmmm, I know I've seen it but when and how often do I acutally pay attention to it anyway and sure enough the outlet I was plugged into was dead. All this M n F'n and it was a dead outlet. So of course I had to ask why the idiot who handled the developement of the error pop up didn't say something like, dock you R4 or check your power" instead of unknown error, contact TS. What a waste of time and crap like this is what burdens TS in the first place and could have been easliy avoided with a proper error prompt. So after all that I was still pissed at AMX for not having the common sense to create a useful error message that would have save myself hours of aggrevation and I can only imagine how many calls TS has received about this.
Comments
We have been able to reproduce this, but only in situations with where there is a marginal connection, and/or a large volume of sustained traffic on the network. There is nothing we can do about the falling offline due to traffic/connection, the not coming back is on our bug list.
There are multiple things wrong with the sleep setup in 3.0.0, only the normal/ideal modes of operation got tested, so a lot of testing here got missed. We are tracking these problems now.
There are 2 separate problems here.
1. When number 2 is fixed, you will have the option to have the remote not sleep(the device will just turn the display off and remain awake) when it is off the cradle, but you will kill your battery life. If you are in the power saving mode(ie sleep), then you CANNOT recieve commands normally. The device is asleep, it is not transmitting or receiving to save power. Any change to how this works will have a significant impact on battery life and thus we cannot see any good reason for making a change in this direction.
2. In 3.0.0, the remote wakeup feature had to be left out for technical reasons. This is where you can use DEVICE_WAKE(device, mode) in the Netlinx code to wake a suspended device. I believe this is currently working in the 5200 panels. As soon as we can get around the technical problems we will try to get this feature in.
It is good to hear that you will be able to send commands to a display sleeping TP/R4 if desired.
When an R4 is used to control every aspect of a home, updated information is very important.
Think about all the unnecessary updates that will be sent if a remote is set to 10 second display sleep (as in a bedroom.)
What about homes with a large number of remotes being used at the same time? This will actually increase zigbee traffic.
Please feel free to call me as I would love to help. I believe a QUALITY working remote is the key for resi dealers to succeed.
Have you looked at the diagnostic page(Protected Settings->System Settings->Page 2->ZigBee Diagnostic) on the R4 to make sure the remotes have a good connection?
Are there any intermitant sources of interference(Microwave, Wireless Access Point, etc) close to the gateway or the remote?
If you have enough remotes active at once that capacity is becoming an issue, then you may want to think about zoning the remotes on multiple gateways. Repeaters are great for extending coverage and fixing dead spots, but they do not increase the network's traffic capacity.
Beyond that, you can use in the master to limit the traffic to a single remote. The remote sends messages to the master when it turns the display on and off(the master typically recieves a WAKE or SLEEP message that can be tracked), the master also knows when devices are suspended or not, and you can enable page tracking. You can avoid a lot of network traffic by only updating the currently displayed page on remotes that are awake. Let the master keep track of all the information, and only send the remote what it needs when it needs it. The only remote/page the user cares about being current is the one they are looking at.
This suggestion goes a long way in creating a snappy system with the least amount of traffic. Update panels on a need-to-know basis only.
Paul
I could not agree more and this was a complaint I've had from the start of the R4 wireless design.
Our home system software has been designed to only send data when a TP/R4 is viewing a section (climate/lights/music/etc.) and the section data changes - no new data, no data sent. The way you suggest, data would have to be sent every time a TP(5200)/R4 awake even if the data has not changed, this would increase network traffic. I guess the next step is to first check if it is online and then check if it needs and update.
I was really M & F'n AMX about this today and of course I didn't check the forums and search for this error number 0x0012 when I first ran into it. I xferred TP files earlier in the week and everything went smooth but today no such luck. Plugged in my base inserted the R4 and I couldn't tranfer, err 0x0012. Remove the USB LAN re-install, several times and no joy. Reboot the R4s, no luck. Closed and re-open TPD4 in between the crashes and no luck. Moved upstairs and xfers OK, hmmm. Back downstairs and try again, no luck. Grab the other R4 that I haven't updated yet, installed in the base and attemp to xfer, no luck. So 3 won't xfer and the one upstairs did so by this point, 4:30 and I killed the main TV set up and I'm M & F'n AMX for another F' up R4 nightmare. Cursed myself a couple of times and asked myself when will I smarten up and stop using these freakin things and finally out of complete frustration caved in and decided to call TS which would be the 5th or 6th time ever. Since I'm over the minimum for free TS I figured maybe they'd be able to help and I can get this set up working again before leaving. Call, entered my ID and got autoferred to sales. Now I'm livid and wanting to smash the f'n remotes since I have tyo talk to sales about my numbers instead of just getting a TS guy to help me with their f'n equipment. Hung up but then decided to call back, talk to sales and ask what the f, I made the quota so where' s my TS but apparently they realized I should have been patched straight thru so they patch thorugh to TS. Told the guy my scenario and the 0x0012 err code and he says, oh that's an error you get when the R4 isn't docked and I'm thinking, can't be, 9 out of 10 times I tried to xfer it was docked and he then asks, did you get the docking pop up and I think, hmmm, I know I've seen it but when and how often do I acutally pay attention to it anyway and sure enough the outlet I was plugged into was dead. All this M n F'n and it was a dead outlet. So of course I had to ask why the idiot who handled the developement of the error pop up didn't say something like, dock you R4 or check your power" instead of unknown error, contact TS. What a waste of time and crap like this is what burdens TS in the first place and could have been easliy avoided with a proper error prompt. So after all that I was still pissed at AMX for not having the common sense to create a useful error message that would have save myself hours of aggrevation and I can only imagine how many calls TS has received about this.