R4 Zigbee Pro
GSLogic
Posts: 562
There is a thread in the ACE section but not all users can view it, so I also started one here.
//////////////////////////////////////////////////////////
ZIGBEE PRO ISSUES:
R4 falls offline - hours later, wake it up and the time is off - reboot, still time is off.
Get time button does not appear to work.
Reconnecting and falling offline seem to take a long time to register.
After coming back online, "Sleep on Display Timeout" is on - idea! remove this button, it's confusing and useless, make the "Sleep Timeout" setting do this.
Not as reliable as first thought, might have to go back to the old version!!!!!!!!
//////////////////////////////////////////////////////////
ZIGBEE PRO ISSUES:
R4 falls offline - hours later, wake it up and the time is off - reboot, still time is off.
Get time button does not appear to work.
Reconnecting and falling offline seem to take a long time to register.
After coming back online, "Sleep on Display Timeout" is on - idea! remove this button, it's confusing and useless, make the "Sleep Timeout" setting do this.
Not as reliable as first thought, might have to go back to the old version!!!!!!!!
0
Comments
I can't quite determine what causes this, but one of the two remotes that I updated to Zigbee Pro decided to try and revert to the old module firmware I'm guessing. I followed the order of upgrade and a day later, one of the remotes popped up and error saying "Error upgrading module firmware" (or something to that effect.) It has been offline since. I'm having my tech upgrade the firmware again.
On the plus side, the range is very good and it seems to be pretty stable for me. Although there are some issues (particularly the ones Gary pointed out), I feel it may be stable enough to keep. I lost my VPN connection to the jobsite so I can't look at the connection logs, but from what I recall, it's only fallen offline whenever I load code and subsequently reboot the system (which is obviously expected.)
I'm going to load it up at my boss' house and have them play with it and see if he's seen any improvements / problems.
Installed 3.0 at four different locations, all with the same issues as earlier mentioned.
AMX needs to fix these issues ASAP!
This version has some great updates once all the bugs are worked out.
NI was already at .422
I wanted to chime in and confirm Gary's findings. Anybody else here that is using ZigBee Pro should too. I'd hope that if enough of us voice our opinion they may acknowledge the problem and possibly fix it.
Ciao
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!
1. After installing firmware in all the R4s (first), than the Zigbee - unplug the Zigbee and the R4 batteries -> reboot - (I'm not 100% sure the unplug has to be done).
2. Go to the "Commissioning" page on the Zigbee browser interface and press JOIN. You have 60 seconds to join the R4. (protected setup -> system setting -> network scan)
VERY IMPORTANT - When you join a remote, it shows up on the Commissioning Page. You must click on its EUI-64 ID and select the “Save/Update Settings” button. This will remove it from the Commissioning Page and then it is bound to that gateway. This way, the remote stays bound to that gateway if it reboots.
3. If transferring to the R4 from TP4, the R4 has to be in the cradle.
The above notes MUST be and should have been added in the install documents.
I am troubled that I had to spend so much time figuring out the proceeder to install this well needed update.
Issues that still exist:
- Get TIME button does not work.
- After reconnecting sometimes TIME is incorrect.
- Reconnecting and falling OFFLINE takes a long time to register.
- After coming back ONLINE, "Sleep on Display Timeout" is on - idea! remove this button, it's confusing and useless, make the "Sleep Timeout" setting do this.
Thanks Gary! Let's hope this is the last of the surprises with ZigBee Pro. I'm exhausted from commissioning one remote! Now let's continue to pound on AMX about the last few issues.
#2 will definitely be a time saver. I wonder if this could be done for the repeaters as well, so I'll check it out tomorrow (new job with 2 R4s, and 2 repeaters.)
Thanks for the tips!
Remember you have to call tech support and get an
RMA for new repeaters, the old ones cannot be upgraded. From what I was just there is a testing ground in Dallas and Rashid is walking around with an R4 with 7 repeaters and it's working flawlessly. I guess this was one if the main changes with Pro. Let us know how it works out(I haven't used repeaters).
Cheers
I'll let you know how it works out - keeping my fingers crossed.
Here is the procedure for commissioning ZigBee Pro Repeaters:
When a ZigBee Pro repeater is first powered on, the top LED (PWR/STATUS) and the bottom LED (RF) will both blink. The PWR/STATUS LED blinks to indicate that the repeater is not commissioned to any network. To commission the repeater, go to the PAN page, Commissioning tab and click on the Allow Joining button which will allow joining for approximately 60 seconds. The repeater will join the first AMX ZigBee network that it detects with Allow Joining enabled. Once the repeater has joined, the middle LED (ICSP) will come on and remain on. The repeater will show up on the Commissioning page and the Connections page. Click on the EUI-64 of the repeater and it will take you to the Pan Device Details page for the repeater. It will show the Extended Pan ID of the gateway to which it is currently joined. If that is the network to which the repeater is to be connected, just click on the Update Settings button and the PWR/STATUS LED will remain on solid. Once this is done, the repeater if rebooted or recovering from a power loss, will boot and look for and rejoin the same network to which it was previously joined.
If the repeater is intended to be commisioned to a network that is not the network to which it is currently joined, fill in the Extended Pan ID with the desired network's extended pan ID and click the Update Settings button. The repeater will then leave the current network and scan for the network with the supplied extended pan ID.
If it is desired to move a commissioned repeater to a new network, press the RESET button for approximately 10 seconds. This will take it back to factory defaults. The PWR/STATUS LED will once again flash and it will attempt to join the first joinable network.
Hope this helps,
S. Johnson
AMX
The old firmware was set to permanently allow joining, but we were required to change this behavior for ZigBee compliance.
Please make sure you get the latest documentation, there was an issue, and the documentation did not get updated when the firmware was released. I believe the latest documentation is now available on the web. There are still some annoying issues with documentation to work out. For example, the allow joining is mentioned in the gateway documentation, which really doesn't help if you are playing around with a remote.
No, it does not, this has been added to our bug list.
To save bandwidth, we only update time every 500 seconds instead of the normal 5 seconds that other AMX panels use. At worst, the problem should correct itself within about 8 and a half minutes. This behavior is identical to how the old firmware worked.
The old R4/ZigBee firmware was using a rather large amount of bandwidth even when it was idle. To fix this we removed or reduced the rate of a lot of messages. The biggest change it the the remote only "checks in" with the gateway every 50 seconds now(The old firmware did this every 20 seconds). This does mean it will take longer to reconnect in some cases.
The worst case scenario is rebooting the gateway, which can take up to 50-60 seconds to reconnect if the timing is just right. Are you seeing anything that takes longer than that?
Edit: I just talked with the other engineer, and we came up with another possibility. If the remote has been trying to connect and failing(out of range, or the network is down) for more than a minute, it will back off on the rate of connection attempts. This may cause the device to take longer to reconnect to the network when the network becomes available. ZigBee compliance requires this as they don't like having lots of devices spamming reconnection attempts.
We cannot remove this feature(some people use it), but it is incorrectly going back to the default value after a reboot. This has been added to our bug list.
Thanks to all your help - I have got it working now.
A bit of instructions would have helped a lot.....
I understand people using it but . . . why? I cannot think of an application where this would be useful. Anyone?
rhargrave, I know you said the time should update within 8-9 minutes, but one of my R4s fell offline last night for around 20 second, after coming back online the TIME was off by 6 hours.
It still has not updated to the correct time yet.
Maybe it's Quantum Physics?
More likely General Relativity from swinging the remote around too fast.
We have not seen any issues with the time being wrong for this length of time, but we will keep an eye out for it.
The feature was put in to deal with problems that arose from the remote going offline every time it went to sleep. In theory, now that we support standby mode, the feature SHOULD no longer be necessary. My experience has been that it is safer to leave features in, because you never know when someone has found a use for them that I never dreamed of.
After getting 8 remotes updated with 4 Gateways I noticed that programming in my R4 was being erased. I would do a "Normal Upload" and this would solve it, sometimes have to upload twice. Then if I would go to Network Diagnostics in the R4 it would erase my programming again. This would only be on certain buttons, hard and LCD. Not sure what to do. Also After leaving the clients home 4 out 8 remotes did not work. I would have to say the others would not either, they probably did not try them.
By erasing I mean that even if I enabled push messages, it would not register. Then I enabled function on the R4 and no response from certain buttons. There were no channel numbers programmed to the buttons.
Also I had remotes fall offline last night and would not come back up. Very Frustrating.
Any Ideas? Im going back today to do "Full Uploads" with system graphics and all. Hope this works. I still have 4 remotes to upgrade but Im a little hesitant.
Jeff
Whenever I'd try to transfer it'd stop at a particular file and had to do the same thing. Different circumstance, same solution. Not sure if that particular problem is specific to the R4 (since I've never experienced that before), or what - but I thought it was worth mentioning.
Talking with Tech Support, if you get into protected Setup and use the "Enter" button on the hard button it will erase some of the channel numbers in th R4. You need to use the "Done" button on the Screen. NOw just need to figue out why remote fall offline and done reconnect without a reboot of the Remote or the Zigbee Gateway.
Close, but not quite. The channel numbers are not erased, the external key inputs are being redirected to the popup keyboard.
Long explanation: In v3.00.00, the R4's external keyboard(cell phone and scrolling text entry with external keys) was updated to work more like the popup keyboards that are on other panels(and thus you can now have text entry on the user pages). There is a bug where if you close the popup keyboard with the external done or abort key, the pop on the screen closes, but the external keyboard thinks the popup is still active. This causes all input associated with external keys to be processed as keyboard input instead of being sent to the master as pushes and releases. If you use the Done or Abort on the screen, the popuop keyboard closes down properly.
A tech note has been released that addresses how and why to upgrade to Zigbee Pro. It can be found at the following link:
http://www.amx.com/techsupport/techNote.asp?id=910
The new firmware updates for the 5200 and the R4 (hereafter TP) prevents the sending of any new data to the TP when they are in the sleep mode. EXP: If you have a TP receiving XM data and the TP goes to sleep, when you awake the TP it would not have received any new data since going to sleep. I can only imagine this is away to save bandwidth and possibly power usage. I could see adding this feature in small systems or if you do not program to handle this issue, but please don't downgrade the overall system to the lowest denominator.
We already handle the idea of this feature in the GSL Home Software (see website below) which only sends data to TPs as needed. This is how we are able to control everything in our systems from any TP or R4. I also do not think the method of sending updates every time a TP awakes is a good practice, as this will increase data traffic in large systems.
PLEASE ADVISE!
When an R4 sleeps while off the cradle, everything shuts down to preserve power. The radio module wakes once every 50 seconds to check in with the gateway. This is done so that the radio does not time out and lose its network connection. This is not new with this release. It has always worked this way. Sleep can be turned off by setting "Sleep Timeout" to zero and turning "Sleep on Display Timeout" off. This will greatly reduce the battery life if it is left off the cradle for extended periods.
S. Johnson
AMX
Thanks for the reply!
Was there a version when the R4 updated when it was a sleep?
I also noticed the 5200 doesn't update when a sleep either, are other panels (CV10, 8400, etc) going to have this feature?
The R4 has never updated while sleeping. The firmware before ZigBee Pro did not have the suspend mode so when it woke there was an online event so everything got updated. In NetLinx Studio there is an AWAKE event that can be used. The following is from NetLinx Studio help:
AWAKE
This keyword defines a section in a DATA event handler for processing AWAKE notifications.
This event is triggered when the master recognizes that a device on the bus has exited STANDBY state.
Once the device is AWAKE, communication to the device from the master can resume.
I can't address the question about the other panels. I have primarily worked with the ZigBee products -- Gateway, R4, R3 and Repeaters.
S. Johnson
A couple of R4 Issues:
#1 - R4s falling offline. Some of the time they come back online, but not always.
#2 - They don't always go to there set "Display Timeout", they just stay ON.
#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.