I’m getting this exception when trying to run an adaptation of green_getting_started.
See both attachments.
-Colin
I tried the test script and it was successful and the X2 gateway has a node type of coordinator. I saw in the code that the DDO timeout value is 30. I’m guessing that’s in milliseconds because it times out almost immediately. Also, I’ve commented out the sensor device and left the wall router which is on always and I receive the same error. I’ve also tried changing the timeout value to 100 and still I get the same error. I’ve been deleting the old dia.zip and restarting the whole process each time I change something to make sure it works. I’m not sure why this exception is being thrown.
-Colin
I forgot to mention the specs for the sensor. It is on sleep mode for 20 seconds and wakes for 5 seconds. The router and gateway are both configured to work together and I have tested reading from them for 24 hour time period to make sure.
Hello,
Based on the line number, the exception is being thrown when the Dia is attempting to retrieve a parameter from the XBee radio inside the Gateway.
If you go to the XBee Network page in the Web UI of the device, do you see an entry with a node type of coordinator? Its network address should be [0000]!.
Also, make sure that you do not have any other python applications running. Turn off anything in the Auto-start settings portion of the Python page in the Web UI. Then make sure to restart the device. This is more of a general check, and I don’t think it would be related to this problem.
If the above suggestions do not yield any useful information, I attached a simple script you can run on the device. It does a simple request of some parameters from the Gateway. You can run it with ‘python test.py’ after uploading it, and post whether it prints out success or failure.
Thanks,
Chris
That function is coded that if other issues occur (parameter not supported, range not supported) it will raise a DDOTimeoutException instead of citing the other issues.
In other words, I don’t think it’s a timeout!
Could you retry it with this modified ddo.py file? Just overwrite the file in src/devices/xbee/common/ddo.py. It just contains information that will help tell us what parameter is causing that exception.
Here are the results:
DDOTimeoutException: Exception occurred with: Retries=0 ext_addr=None param=DD
Interesting! It seems to be failing on the coordinator when requesting the DD AT command, which is used to help identify the device and protocol it is using.
If you could type the following commands into the CLI of your gateway and reply with the results:
set mesh DD
set mesh VR
set mesh HW
#> set mesh DD
error: value required for dd
#>
#> set mesh VR
error: value required for vr
#>
#> set mesh HW
error: value required for hw
I’m not familiar with the command, but I might be missing something.
You may be running on a older firmware. I am running the 82001115_F release on the CPX8, which is equivalent to 82001596_E1 for the CPX2 in terms of release.
To check what firmware version you are running, you could do the command ‘info device’ on your CLI. I think the third row down shows the version. Could you post this as well? I’m curious what firmware version makes the ‘set mesh’ command require a value.
If you aren’t running E1 firmware, could you get the firmware http://ftp1.digi.com/support/firmware/82001596_E1.bin and upload it to the device.
Once you upload the new firmware, could you retry the commands earlier?
Device Information:
Product : ConnectPort X2
MAC Address : 00:40:9D:37:22:03
Firmware Version : 2.7.5.3 (Version 82001596_C 07/16/2008)
Boot Version : 1.1.2 (release_82001228_A)
Post Version : 1.1.3 (release_82001229_D)
CPU Utilization : 20 %
Uptime : 1 hour, 17 minutes, 42 seconds
Total Memory : 8388608
Used Memory : 5146412
Free Memory : 3242196
I don’t think it’s been updated for a year so it makes sense. If I update the firmware, will it have any effect on my sensors or wall routers?
And will I need to update the boot/post too?
The boot doesn’t have to be upgraded.
The post could be upgraded too, and I would recommend so. File is: http://ftp1.digi.com/support/firmware/82001229_F.bin
I don’t think it matters about order, but I’d do the POST first.
Here’s the results after the upgrade.
#> set mesh DD
DD: 131075 0x00020003
#>
#> set mesh VR
VR: 4417 0x1141
#>
#> set mesh HW
HW: Not supported (-98)
Alright, I accidentally gave you the command HW instead of HV, but it seems like that doesn’t matter (Its the hardware version of the radio). You’re running Znet 2.5, 0x1141 which supports the DD parameter.
If you haven’t retried launching the DIA, I’d try that and see if the same issue pops up.
I retried it and its working, but i can’t seem to get the webpage up. I received a memory error when it started up, but it kept going.
Also, I reset the gateway after it had been running for a while and automatically ran DIA. I checked the auto-start settings and all fields are empty.
The ConnectPort X2 only has enough memory to run a single presentation. Try editing your iDigi Dia configuration file and disabling the console presenation by adding ‘#’ marks in front of it.
Please see the attached configuration file to see what I am talking about…
Regards,
Jordan
Thanks. That seems to be working.
I took a look at the amount of memory used when running DIA and have only a small amount left running 20 sensors and I noticed you said the ConnectPort X2 only has enough to run 1 presentation. Does this mean if I upgrade to X4 or X8 I will have more memory to run more presentations?
-Colin
Yes,
The X4 and X8 products are produced in 16 MB and 32 MB RAM varients. You would have much more memory!
The X2 currently only has 8 MB of RAM.
Jordan
Sounds like I’m gonna upgrade if I’m potentially going to have 100 sensors.
Thanks for your help.
-Colin
Smart move - I always tell people “Save yourself heart-burn … do basic development on the wonderful (really) X4, then once you are done, then work to ‘reduce’ the application to perchance run on the X2”
Digi is selling an X4 starter kit for $150 (see http://www.digi.com/products/wirelessdropinnetworking/drop-in-networking-kits/)
Keep in mind that during development you add lots of debug info and so on. So you code will naturally be larger than required in the final product.
Not only that, in the X2 a failure due to no memory is harder to understand than working on a X4 trying to “reduce” the memory usage of a nicely running program.