I am having a problem using iDigi to set up the IA module on a CP X4 to communicate with a Zigbee RS485 adapter.
iDigi will not accept the ‘!’ at the end of the ID of the Zigbee device id. Leaving it off seems to give me something that doesn’t work.
If I set the route up through the X4’s web interface, I leave the ‘!’ and it works fine, not without it. Viewing the working route on iDigi, it flags an error on that entry.
For any Digi folks who watch this, I encountered a couple of other rough edges that I’d like to mention:
Tables and routes in the IA configuration are labeled 1,2,3, etc., but it seems you have to use an index of one less than what they are labeled when setting up references.
In my experience, changes on iDigi don’t necessary show up on the device’s web interface and/or vice versa. Hard to figure out how things are being set up.
In iDigi’s setup page for a Zigbee device, are we really supposed to figure out that a ‘4’ means 19,200 baud?
Some on-line ‘help’ would be nice.
The iDigi layout is significantly different from the device’s web interface. Shouldn’t clarity and consistency of interface design be a priority for Digi?
I want to acknowledge iDigi’s many wonderful points. Is is an incredibly useful tool. The other day an X4 that I thought was lost in space because of my own error magically reappeared, and I still haven’t figured out how.
Getting an RS485 to work on a CX4 using the Industrial Automation settings took me a bit of trial and error. But now I have lots of CX4s running with RS485 adapters talking to dozens of modbus devices spread across several sites. The information on how to configure the CX4 and RS485 Adapter for IA is out there, but scattered around.
I am providing settings that work for me, but you may have to adjust them to suit your environment. Here you go:
RS485 Adapter
Make sure the A & B RS485 wires are connected with the correct polarity with your slave device.
The Dip Switches on the back of the RS485 Adapter are as follows:
UUUDD Where U=UP and D=Down - See wiki for details.
The following XBee settings work for me when setting up an RS485 adapter via the Gateway or X-CTU
Flow Control (D7) unchecked!!! MUST be unchecked.
Destination Address (DH/DL) = address of Gateway (Example: 00:13:a2:00:40:33:01:8d!)
Destination Endpoint(DE) = 0xe9 This allows a mixture of Modbus and Digi sensors (like a wall plug) on the same CX4 Gateway
Baud Rate(BD) 9600 or whatever your modbus slave needs
Parity(NB = None or whatever your modbus slave needs
(Most of the following probably don’t matter except for D7)
D0 = 1
D1 = 0
D2 = 0
D3 = 0
D4 = 0
D5 = 1
D6 = 0
D7 = 7 MUST BE 7 so it send out packets!
P0 = 1
P1 = 0
P2 = 0
Index gets generated automatically, but take note that this determines the sequences the IA engine routes messages. So for example if you accidentally have 2 routes with a slave ID = 4, the first destination will get the message.
You can change the sequence with the Up / Down actions.
Address= SlaveID or range of addresses
Protocol = Modbus/RTU
Destination= RS485 XBee address WITH !e9 AT THE END!!!. Example(00:13:a2:00:40:4b:a6:83!e9)
The e9 is the endpoint to route the message that matches the RS485 setting above.
There is a lot of useful info on the iDigi Wiki on Modbus / RS485:
Just reread your post and your question is about iDigi settings. I use iDigi once the CX4 is out in the field to make changes and I have successfully managed RS485 adapters. It is a little different than the local web interface, but it has corresponding values.
ONE IMPORTANT NOTE!
Be sure and have the latest firmware on your CX4 (currently 82001536_H1). There was a bug before where the RCI was not storing the zigbee and this version fixes that. There is still a bug where the Min and Max protocol addresses are always a garbage value, but you can manually change it to the correct slaveID before saving or importing. I submitted ticket and it should be fixed in the next 2 weeks with another firmware release.
Thanks so much for this, you’ve saved me lots of time. So far I have missed both the flow control item and the need for the e9 on the destination.
It is interesting that I’ve been able to configure and run correctly using the web interface without the e9, whereas iDigi will not allow it.
It does seem like the firmware is improving rapidly. Testing with an older version, I managed to completely lock up the X4 with a wrong setting (sorry, don’t recall what), but the new FW is much more robust.
I think I declared victory too soon. I seems as though I simply cannot set up an IA route to a Zigbee adapter using iDigi. iDigi will not accept the Zigbee device id with the trailing ‘!’ (or with the additional ‘e9’), and the IA doesn’t work with the Zigbee adapter without it.
You are correct. iDigi will not let you add a brand new ia_route with an “!” at the end. I would write up a ticket on that.
The reason I had not noticed that is because I “export” and modify the RCI file directly and “import” it in.
Here is a workaround that may work for you.
From the first iDigi screen that shows the devices do a mouse right-click on the CX4 and select “Administration/Export”.
This produces and downloads an xml file in RCI format.
Scroll down in the XML file until you get to the first
Paste in a new ia_route entry, such as the following:
ononoffmodbusrtuzigbeetcp044route00:13:a2:00:40:4b:a6:83!e9210100offauto250025005005000mediumoff0offreplace0
Now add a new entry to the 0,1,2,3 - Each entry represents an
Save the file and “Import” it back into the CX4.
Reboot
The iDigi data entry screen will now show the new ia_route with the “!e9”. It still shows it as having an invalid ip address, but it works and the CX4 will route messages to it.
That is coming - the field for the MAC was previously defined as a well-qualified domain name, so an IP or DNS name worked, but the 802.15.4 MAC (with or without the !XX) would not be permitted by iDigi. iDigi ‘learns’ about these fields on the fly by querying the X4’s firmware remotely, so a new firmware is required.
I have been testing with strings like 00:13:a2:00:40:0a:22:9b!E9 and so on - it will just become a string. That way iDigi won’t care, and the X4 will still validate it any garbage you enter. No Beta code available yet.
I did create a Wiki page about setting up an IA config via iDigi. This example is NOT for ZB, but for localhost to talk Modbus to a Python program, but once the device firmware properly supports ZB MAC, then I’ll update the example.
Thanks, Lynn, that addresses exactly what I have been trying to do. And mostly failing.
I did encounter one really strange thing that I want to mention. I had set up a table, a master and 2 routes (one to a ZB RS485 adapter, the second to a Python program), and for the heck of it decided to export and inspect the (RCI) XML, where I was surprised to see the table definition appear in Table 2, although it showed up in iDigi as table 1. In this case it happens I’ve not yet made the second route work (and don’t yet know why).
On a test unit supposedly set up the same (but entirely with the web interface), this didn’t happen (and both of my routes are working).
Unfortunately, I think you’d need to do a factory reset to clear ‘old notions’ of indexing.
That off-by-one issue is a side-effect of iDigi just blinding using the RCI without understanding the context. The web/telnet see table=0 and show you table=1. RCI saves as table=0, however if you create a table & delete it, that doesn’t actually clear the entry because some Master or route might refer to it. So the programmer was over ambitious and will give your next new table a different index to avoid surprises.
I would think if you manually force everything to be table=0 via iDigi, then you should be okay because the 4 sets of data are 100% ‘un-relational’ in that you are responsible to point Master and route to the table, and the table to the route list in the desired order. The Web UI/telnet try to protect/help you, iDigi just treats them all as unrelated.