Hi.
I encountered a problem while trying to execute dia on connect port x8. Using Putty the command
given was python digi_dia.py digi_dia.yml
The output was:
Digi Device Integration Application Version 1.1.7
Using settings file: digi_dia
Core: initial garbage collection of 1182 objects.
Initial settings file not found, aborting start up…
The operations performed on the device before trying.
-python.zip updated
-digi_dia.py loaded on the device
-digi_dia.zip created using make.py and aplying the digi_dia.yml file to the zip
-digi_dia.zip loaded on the device
Could you try just running ‘python digi_dia.py’? That should cause it to look for the settings file in the zip file.
If you decide to upload the settings file to the device separate from the one in the zip, you can make use of the settings file argument to specify the name.
it actually worked untill i had to use the Xbee manager with dia to connect my temperature sensore to the connection port x.
course of actions
-Edited the demos\getting_started\digi_dia_xbib.yml
the xbib0 instances extended_address to match
my xbee sensors mac address (pic1)
-Compiled the xbib file to the dia.zip file with
python make.py demos\getting_started\digi_dia_xbib.yml (pic1)
-Uploaded the new dia.zip and rebooted the device
-Tellnettet to the device via ip 192.168.1.1 port 23
-tried running the digi dia with the xbee manager
1) #> python dia.py digi_dia_xbib.yml
2) #> python dia.py
*result (pic2)
3) #> python dia.py dia.yml
* giving me the good old “Initial settings file not found, aborting start up…” bit
Ok so i decided to try and work with the error message when running
#> python dia.py
I uploaded all the .py files mentioned in the traceback part of the error to the device
*Outcome error message (pic3)
-tried to upload the classloader.py
*that just messed up the whole system so badly that it gave me
“Unable to start interpreter thread”
I think your pic2 error is because you didn’t restart your GateWay once the Dia initialization failed, so it tried to make a bind but it couldn’t because the socket was already opened. Also, seeing the files you have updated to the GW, I think you are getting the ‘Initial settings file not found, aborting start up…’ error because you write ‘#> python dia.py digi_dia_xbib.yml’ command but you haven’t got the ‘digi_dia_xbib.yml’ file inside the GW. What I would try is to upload that file to your CPx8 and then execute the command ‘#> python dia.py digi_dia_xbib.yml’.
Notice that you should reboot your GW each time the Dia initialization fails or you upload a new dia.zip file to have a fresh environment.
Hope it works.
Regards.
PS: You can delete those files you transferred to the GW mentioned in the traceback part of the error to the device, they are included inside the ‘dia.zip’ file.
Hi everyone.
So i tried what diegoe suggested. It didn’t seem to help but it did help me come up with some ideas about what i’m dealing with here.
So the suggestion was to try to upload the digi_dia_xbib.yml to the GW and after that execute the command
#> python dia.py digi_dia_xbib.yml
So i did that and the program gave me the same error as in pic2. I ended up trying variations of the suggestions combined with the manual books text so these are the thing i tried.
1)- do the make.py rutine on the dia.yml
upload the dia.zip to the CPx8
reboot
upload the digi_dia_xbib.yml
run th "#> python dia.py digi_dia_xbib.yml
error message pic2
(Also tried rebooting after uploading the
digi_dia_xbib.yml and after the error message)
2)- Do the make.py rutine on the dia.yml
upload the new dia.zip
reboot
Do the make.py rutine on the digi_dia_xbib.yml
upload the new dia.zip
reboot
run dia with #> python dia.py
error pic 2
reboot
run dia with #> python dia.py digi_dia_xbib.yml
didn’t find the .yml file
reboot
upload the digi_dia_xbib.yml separatly to the CPx8
reboot
run the digi dia #> python dia.py digi_dia_xbib.yml
error pic 2
So at this point after metaphoricaly banging my head into the wall. I came up with some conclusions.
conclusion
when you execute the make.py command on an .yml file it impliments the .yml file into the dia.zip file as dia.yml
so when running the dia.py it automatically uses your
setting file without calling it separatly.
I came up with this when i noticed that it gave me the same error every time i tried to run dia with the xbix setting fiel. This conclusion brings me to the 2. conclusion.
conclusion
The problem i think lies in the digi_dia_xbib.yml setting file.
*I noticed that dia works perfectly until implimeting this setting file.
So does anybody have any idea how to configure this file or how to get a different version or something to by pass this problem and still use the Xbee sensore with dia.
p.s : I would like to thank everybody for helping. Just need some backup a litle bit more.
File “”, line 1, in bind
error: (22, ‘Invalid argument’)
In that case, take a look to the Auto-start Settings from your CPx8 to check if there is any application using an XBee socket that starts automatically .
To do that go to the CPx8 main page. In the ‘Applications’ section click on ‘Python’, and under the file list of your CPx8 you will find the ‘Auto-start Settings’. Check if there is any application configured to auto-start with the device’s boot.
Hi, Diego.
So I did look to in the auto start settings and found that the zb_tcp_serial.py was auto starting on boot. So i disabled it and tried to run the dia.py with the configured setting file. It worked. Or at least i could connect to the dia cli. So was the zb_tcp_serial.py blocking the socket or something? Could are the pics channel values okay beacouse I’m not sure. I have one xbee sensore connected to the CPx8.
They really should mention the zb_tcp_serial.py taking up that socket. I think that it is a defalut setting.
> They really should mention the zb_tcp_serial.py
> taking up that socket. I think that it is a default
> setting.
No, This is not a default - that is just another demo script someone uploaded and enabled on your X8.
The real fault here is in perhaps the error wording - it would be nice if the error literally said something like “I can’t control the Zigbee socket - confirm no other python script is running.”
In general Python scripts never share things like the Xbee socket gracefully. In part this is a limitation in Zigbee - I have some Modbus code which allows a dozen threads to “share” a mesh of Modbus serial slaves. The problem is when packets come back, the single thread managing the socket can’t absolutely know which thread wants the answer. There are ways one can “hint” at the client id, but many of these work-arounds assume the remote node cooperates in ways that they can’t be trusted to cooperate. I thought about trying to track MAC or Modbus slave address etc, but that required too much Modbus & timing knowledge at the wrong level. So today my single “socket manager” thread just offers the response to each running thread, and they accept or reject based on their own expectations.
I bring this up only because if you did want 2 or 3 distinct python programs to “share” mesh access for something common and fixed like “transparent serial data”, then one program needs to be the manager and the others proxy through the manager.
Well the reason the channels are led1, led2, led3, sw1, …, sw4 is because you have configured the Dia to use the driver for the XBee development board. This comes from the following line of the yml file:
There is an example yml file with a light/temperature sensor configured in it in the demos/xbee_sensor directory. You can update the extended address in that file with the address of your sensor, and then try it out.
So i seem to get connected to the dev board and the Xbee temperature sensore with dia. But when using dev board setting all sw seem to be false though they should be true unless pressed on. Also when i press on them nothing happens. the connection is working at least a little beacouse i can switch the leds on from my CPx8.
What does it actually mean when the led4 and the red led on the left of the serial are blinking in turns.
Also with Xbee Temperature rensore i get -52.00 Celsius when it should be about 25 c or something like that.
I haven’t worked on either of those hardware pieces, however understand that Dia is a timed-sample system. Most uses of low-power battery don’t want instant access because it costs too much power-wise.
If your Dia/host is set up to poll, then it would only see any switch pressed if you held it long enough to be seen during a poll.
Now a Zigbee node can be set up to only talk when some condition is true - like a button press. Unfortunately that means the host could not tell it to toggle an LED at will. So this is your classic cannot-have-cake-and-eat-too. This is not your typical single-board computer demo which is 100% available to do as you desire.
Just for fun/education I signed up for iDigi last night and downloaded the files. Make sure you see the getting-started PDF as the text files in the dia/doc directory seem to be outdated. So you may want to take a step back and read that PDF (it covers most of the issues you have posted so far), also try the getting_started.yml and not building your own.
Technically, an XBee module has 16 digital I/O lines packed into a word. How those are interpreted is product & setting specific - so what is LED2 output on that dev board might be DSR input on an RS-232 module. The XBee is agnostic to such things. Aim the wrong host software at the wrong hardware and the result is confusion.
Also, any analogs move as values in range 0 to 0x1024. Again, the Xbee is clueless about what that means - it is just a voltage signal converted to bits. If there is nothing attached, it is utter garbage and the Xbee won’t know. If your temperature is so far off, the most likely cause is your dia “host config” is misinterpreting one of those numbers - for example different hardware have the temperature on different inputs. Sounds like a config issue.
I have red the dia pdf. files the first and the secon one that cover this. Im goint to illustrade the problem by uploading a pic where you can see the manual and what i get when telnetting to the dia cli. So i don’t think that problem is in the dia compatibility.
I see in your channel dump that there haven’t been any samples pushed up to update the state of those switches. I noticed in code that the default value for those channels is False…
Did you try pushing any of the four buttons on the development board? I’m thinking that if you push each of the four buttons, they’ll start showing up as true as soon as you let them go. Also, you may want to try doing a channel dump while you have one of the buttons pushed down, to see if its state is different than the rest.
As for the light and temperature sensor…it would be helpful if you could post the section of the yml file where you have the sensor configured, as well as a capture of the channel dump like you provided for the development board. Also, provide a log of what is printed when you run Dia with the sensor configured. That should provide some insight into why your sensor is not pushing up reasonable values.
XBeeSensor(sensor0): DD info (module_id, product_id) = (0x0002, 0x0007)
It looks like you’re actually using the Sensor Adapter product with a WatchPort Temperature sensor plugged into it. That is different than using the LT or LTH sensor product.
The introductory documentation is geared more toward the iDigi Starter Kits, and it sounds like you probably have the components from the earlier Drop-In Networking Starter Kit. Everything should still work fine though.
You can try changing the driver from devices.xbee.xbee_devices.xbee_sensor:XBeeSensor to devices.xbee.xbee_devices.xbee_watchport:XBeeWatchportSensorT
The settings for the two devices happen to be the same, so only changing the driver is necessary.
Check if your Xbee module is configured in sleep mode. In that case you should configure the Xbib driver in the YML file, setting the “sleep_ms” with the same value as the module’s SP time. (Remember that SP time can go from 0x20 to 0xAF0 x 10 ms, so the minimum “sleep_ms” configured in the driver must be 320 ms, and the maximum 28000 ms).
If your module has sleep mode but you don’t specify any “sleep_ms” in the Xbib driver settings of the YML file, you won’t be able to read the switch channels of the Xbib board and you’ll see their values always in “False” (the default initial value in the driver).
iDigi Device Integration Application Version 1.2.19
Using settings file: digi_dia_xbib.yml
Core: initial garbage collection of 0 objects.
Core: post-settings garbage collection of 28 objects.
Starting Scheduler…
Starting Channel Manager…
Starting Device Driver Manager…
Exception during dynamic class load:
Traceback (most recent call last):
File “C:\DIA\src\common\abstract_service_manager.py”, line 195, in service_load
File “C:\DIA\src\common\classloader.py”, line 52, in classloader
File “C:\DIA\src\devices\xbee\xbee_device_manager\xbee_device_manager.py”, line 83, in ?
ImportError: No module named zigbee
Exception during core initialization:
Traceback (most recent call last):
File “C:\DIA\src\core\core_services.py”, line 235, in epoch
File “C:\DIA\src\devices\device_driver_manager.py”, line 57, in init
File “C:\DIA\src\common\abstract_service_manager.py”, line 105, in init
File “C:\DIA\src\settings\settings_base.py”, line 175, in init
File “C:\DIA\src\common\abstract_service_manager.py”, line 121, in apply_settings
File “C:\DIA\src\common\abstract_service_manager.py”, line 148, in _reenumerate_services
File “C:\DIA\src\common\abstract_service_manager.py”, line 200, in service_load
ASMClassLoadError: unable to load ‘devices.xbee.xbee_device_manager.xbee_device_manager:XBeeDeviceManager’: exceptions.ImportError:No module named zigbee
CoreServices: fatal exception caught! Halting execution.