Can't set ia route destination type = zigbee via iDigi connect server

I am working with a remote CX4 Gateway via the iDigi Connectivity server.

If you are trying to add an XBee RS485 adaptor (or any Xbee device that will accept Modbus messages) there does not appear to be a way to set the “ia route destination type” to zigbee. The only values in the drop down for the destination type are: nopath, serial, directip, discard, mapto.

How do I set the value to indicate that this is an XBee device? The default is “nopath” and you can’t leave it blank.

I tried setting the value via RCI, but don’t know what the value should be. I tried “xbee” and “zigbee” but they are rejected with an error message saying these are invalid types. I tried sending an empty value and it is accepted, but messages do not get routed to this device.

I did an “export” to see what the settings are for a known good Gateway with Xbee destination routes and there is no parameter in the response values for indexes.

Any help would be appreciated.

Howdy - your X4 firmware is new, correct? If the Web UI doesn’t have the XBee option, the firmware is old or the XBee coordinator is disabled or not responding.

Or trying to read between the lines, you are saying that you want to use RCI to remotely update the IA table? Is this a remote iDigi issue?

Hi Lynn, Yes this is a remote iDigi issue. I am working with a remote CX4 Gateway via the iDigi Connectivity server.

The CX4 is behind a firewall and so I have to use the iDigi Connectivity server to update it. The iDigi Connectivity Server does not have the option to indicate that this is an XBee destination in the ia_route table. How do I create a new ia route with a destination type = zigbee via the remote iDigi Connectivity Web site?

Any thoughts? I don’t think the CX4 firmware handles “XBee” destination types via RCI. I tried doing a Backup and then a Restore via the CX4 web interface and my XBee routes were cleared out.

I created a failure on it - to fix the iDigi server. The RCI probably works but order of settings is very fussy. Put something in the wrong order and it gets skipped.

One short-term work-around is to create a simple Python script which uses the CLI to force in a telnet line remotely to add your single line.

Lots of todo for me. I should study the RCI more, see what magic is required. I’d also like to create a simple Python script which adds any/all RS-232/485 adapters seen but missing from the IA table to the end of the table - you’d only run it on demand as a one-short.

Won’t have time for these for weeks.

Thanks Lynn,

If the RCI can be made to work by entering the values in a certain sequence, that would be acceptable as a short term solution.

Let me know if you want me to try anything. I have a good test environment set up.


What version of X4 firmware are you using?

Working towards an answer. I was returned notice that the X4 doesn’t correctly inform iDigi that Xbee is an IA Route option.

Unfortunately and the timestamps are now in GMT . I am in the process of downgrading to previous version and will have to clean up all of the stored data in my database.

Actually, I think the timestamps have always been “per the RTC”, but the problem was different time sources provide UTC or localtime. So the older firmwares risk your time “changing” by your time-zone if the time source changes. For example we’ve had large customers complain because 60% of their devices use SNTP, so timestamps were UTC and 40% were cellular, so localtime.

Trying out the latest firmware…

Actually, looks like has fixed this. The type element now has zigbee.

However, the following elements are still not being passed correctly from the CX4 using RCI:


In my configuration, the values should be “7” for both.

Try doing a “backup” and then a “restore” from the local CX4 web server and the min/max values get set to “any” instead of the original values.

Looks like we should have a new firmware with the IA config working from iDigi next week (6 or 8th Dec).

As for the time.localtime() - yah, that’s ‘re-busted’ in 2.12.x after being fixed in 2.10. Will be interestign to see what it’s status is in the next week stuff. For now I’ve just been disabling time-zone & runing local time in the RTC as ‘UTC’.