This is also posted in Wicked Devices Q&A but I'm not sure where the issue is..
First my Dust sensor needs a firmware update, I know that that's not an issue, And my Humidity sensor is unreliable too, but that's irreverent to this....
My Eggs intermittently locking up, My feed is here - https://xively.com/feeds/124233 if you look at the RAW feeds (or the sample image file attached) you can see they look nicely "jaggy" till around 12-10 ish here in the UK, then become stepped which suggests the uploads have stopped and its intermittently reporting data points at around every 30 mins rather than a regular flow of data points.
Not all data points stop at the same time, CO became stepped around 12-30, NO2 around 12-10, 03 went to about 12-40 ish, and the VOC got to maybe 12-05 to 12-10.
The eggs were flashed on the 7th of August when I fitted the 03 and VOC sensors, and the code was downloaded form GitHub at that point.
I've put a FDTI cable on the Egg Base and the key points are
****Power on****
[Air Quality Egg - Base Egg - v2.01]
Egg Serial #: 00:04:a3:8c:1b:ac
IP: 192.168.2.195
GW: 192.168.2.1
DNS: 192.168.2.1
Stack: 154
SRV: 64.94.18.121
Packet Received @ 35188
It then logs OK, but after a while reboots, Last entry before the reboot is
Sensor Type: VOC
Preparing stash
Sending data to Cosm
Data sent Packet Received @ 659490
Sensor Type: Dust_raw
Preparing stash
Sending data to Cosm
Data sent
Too Long Since Last Response From Cosm,
Resetting
I'm getting very few response received entries, but at the moment there's nothing really happening on the home LAN during the day, and when it reboots it talks to COSM to be provisioned almost immediately. There's no pattern to the the loss of connectivity I can see, sometimes it works for days other times it resets withing 20-30 minutes of a power cycle.
Anyone have any suggestions.
I had a problem with exactly these symptoms a while back and discovered that it came about when my AQE was behind a firewall that does SPI (stateful packet inspection). The TCP/IP code the AQE uses and my very picky firewall don't always agree on what sequence numbers are reasonable in the packets the AQE sends to COSM. The firewall sees the packets with what it considers unreasonable sequence numbers as bogus and blocks them.
When I put the AQE behind a firewall without SPI, the problem went away. Since the SPI firewall is happy with all of the other TCP/IP devices I have behind it, I suspect the code package the AQE uses.
I never did go through the code to try to figure out what, precisely, causes the SPI test in the firewall to fail.
Hope this helps,
David Ehnebuske
Thanks, I've given the AQE a fixed IP, and moved the AQE into the routers DMZ and we'll see how that goes.
For what it's worth and on the off chance anyone else has it, I have a Dlink DIR-655 Hardware A1/A2 Firmware 1.37EU
David,
That is a really interesting note, thanks for sharing it! I wonder if that is resolved in the latest and greatest Ethercard library on github.com/jcw... care to test or give network setup details for sometime to reproduce?
Regards,
Vic
> --
> You received this message because you are subscribed to the Google Groups "#AirQualityEgg" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to airqualityeg...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Not making much difference for me.
Tried putting the AQE in the DMZ and got no real change, I since turned off the SPI firewall and still nothing.
What needs updating in the Ethernet shield, I've only known about jmsaavedra/Air-Quality-Egg on github. If you can point me to wards the code (and give instructions I'm happy to experiment here.
Gavin
By the way the version of the Ethercard package I'm using is later than the one that shipped with my (early-version) AQE. It contains a fix to a problem that I reported here and on github for the Ethercard project. The problem occurs with the Dlink DIR-655 router Gavin's using. Prior to this fix the router and the AQE sometimes wouldn't agree about whether the AQE had been assigned an IP address address in response to its DHCP request for one. The router thought it had but the AQE thought it hadn't. The result was that the AQE kept asking over and over and getting the same answer (which it didn't properly understand).
David
Maybe I tried too much at once..
Reserving it a DHCP address didn't help, it just didn't connect for an hour, the LEDS's blinked to say it was provisioned but the data never got to Xively and it reset.
I'd also put it in the DMZ and turned off SPI so not sure what the cause was.
So
Initial "normal" DHCP mode, works for a few hours then it fails to communicate.
Current mode Still in "normal" DHCP mode, but SPI disabled. Egg rebooted about PM yesterday, ran to about 1AM (4 hours) before the output became stepped again suggesting intermittent comms rather than "real time" comms.
NO FTDI log as the laptop wasn't connected.
Will reboot before I go to Work and see how long it lasts, and set up the laptop to log output tonight. Is there any other was to log the output that the Arduino Serial monitor that can write to disk, had the problem with the first ruin that a Windows update rebooted the PC and it lost the collected data..
Gavin,
You have to mod the software for static IP, right?
Regards,
Vic
Static was bad choice of phrase.
I had reserved the address on the router so the aqe always got the same address and so always ended up in the dmz.
It's not a true static but does the same thing.
Egg serial dump...............
Sensor Units: %[Air Quality Egg - Base Egg - v2.03]
Unit Address: 00_04_A3_D9_34_B3
3611 Received Packet During Pairing
85 0 4 163 217 52 179 0
Pairing Event Count: 1
Pairing complete
Egg Serial #: 00:04:a3:d9:34:b3
IP: 10.2.xxx.39 //hidden IP on purpose
GW: 10.2.xxx.1 //hidden IP on purpose
DNS: 10.xxx.2.1 //hidden IP on purpose
Stack: 149
DNS lookup succeeded.
SRV: 64.94.18.120
Previously provisioned
Packet Received @ 57564
Packet Type: 33
Remote Firmware Version: 33
Remote Station Address: 00_04_A3_D9_F_8A
Source Sensor Address: 00_04_A3_D9_F_8A
Sensor Index: 0
Sensor Type: Temperature
Sensor Units: deg C
Sensor Value: 24
Sensor Type: Temperature
Preparing stash
Sending data to Cosm
Data sent
Packet Received @ 62844
Packet Type: 33
Remote Firmware Version: 33
Remote Station Address: 00_04_A3_D9_F_8A
Source Sensor Address: 00_04_A3_D9_F_8A
Sensor Index: 1
Sensor Type: Humidity
Sensor Value: 37
.
..
...
TOO LONG TO PRINT (all the sensors data Sending to Cosm)
...
..
.
Sensor Type: Dust_r0
Preparing stash
Sending data to Cosm
Data sent
Packet Received @ 603663
Packet Type: 33
Remote Firmware Version: 32
Remote Station Address: 00_04_A3_D9_F_8A
Source Sensor Address: 00_04_A3_D9_24_06
Sensor Index: 0
Sensor Type: Dust
Sensor Units: pcs/283ml
Sensor Value: 0
Sensor Type: Dust
Preparing stash
Sending data to Cosm
Data sent
Too Long Since Last Response From Cosm, Resetting
Stack: 229
[Air Quality Egg - Base Egg - v2.03]
Unit Address: 00_04_A3_D9_34_B3
Pairing complete
Egg Serial #: 00:04:a3:d9:34:b3
IP: 10.2.XXX.39 //hidden IP on purpose
GW: 10.2.XXX.1 //hidden IP on purpose
DNS: 10.xxx.2.1 //hidden IP on purpose
Stack: 149
DNS lookup succeeded.
SRV: 64.94.18.120
Previously provisioned
Packet Received @ 35101
Packet Type: 33
Remote Firmware Version: 33
Remote Station Address: 00_04_A3_D9_F_8A
Source Sensor Address: 00_04_A3_D9_21_2B
Sensor Index: 0
Sensor Type: NO2
Sensor Units: ppb
Sensor Value: 55
--
You received this message because you are subscribed to the Google Groups "#AirQualityEgg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to airqualityeg...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.