Hi @mwyllie, let me start by emphasizing that we are here to help in any way we can. Air Quality Eggs talk to (at most) three different servers in the course of their operation. The first two are only contacted during startup.
The Egg checks for ‘over-the-air’ (OTA) firmware updates (by default) at update.wickeddevice.com. The request one or two files from this site; one small file to verify the signature of the firmware they are already running, and one to update their firmware image if their current signature doesn’t match (so usually it will only be one small file fetched). Eggs can be configured to skip this step by issuing the command
updatesrv disable using the command line interface; they can even be configured to reach out to a different
update server using the same command. At this time, update.wickeddevice.com is hosted on a Digital Ocean server. The update server is a standard web server operating on port 80.
The Egg attempts to synchronize its internal clock with a Network Time Protocol (NTP) server if that capability is enabled. By default this is not enabled, and the capability is described in a bit more detail in this blog post. At this time, the default NTP server the Egg talks to is pool.ntp.org, and in the next firmware update, this is expected to change to 0.airqualityegg.pool.ntp.org. Neither of these are servers that we administer. You can also configure an Egg to talk to an NTP server of your choosing, using the command
ntpsrv your.ntp.server.com. NTP is a UDP protocol operating on port 123.
After startup, the Egg communicates with an MQTT server to publish its data to the internet periodically. By default messages are currently published every 5 seconds on most models, but can be configured differently through the
sampling command at the command line interface. One message is published per sensor type / topic, depending on model that is 4 or 5 small messages being published every period. I’m planning to change this default behavior to publish once a minute in the next firmware release. Currently, all eggs publish to the OpenSensors.io MQTT broker at mqtt.opensensors.io. I believe OpenSensors hosts their services on Amazon AWS, and MQTT is a TCP protocol operating on port 1883.
So I think what you see there is in line with expectations as to which servers the Egg calls. If your Egg works at home and does not appear to work in an “enterprise” network context, this is typically because of additional security measures being in place on that network. The most common cause I’ve seen has been the presence of “captive portal” technology.
If a foreign computer comes onto your network and attempts to use the internet (e.g. browses to google.com), and it is confronted by a page asking you to “log in” or otherwise accept terms of service before being allowed to reach the broader internet, that’s what I mean by a captive portal. The Egg is not equipped to handle such a scenario, but most such systems allow a network administrator to make exceptions for allowing “headless” devices by registering their MAC addresses in a “white list.” You can get your Egg’s MAC address from the command line interface from the Network Settings section of the configuration logs that are reported after typing
get settings, or you can type
get mac to cut to the chase. It will be a string of pairs of letters (a-f) and numbers, separated by colons (e.g.
Another thing that might be helpful is that, if your network administrator requires it / wants to take advantage of it, an Egg can be assigned to use Static IP configuration instead of Dynamic (DHCP) configuration (which it uses by default). You can do this using the
staticip command from the command line interface which requires you to provide: Static IP address, Netmask, Default Gateway IP address, and DNS server IP address.
Hopefully this is helpful, but please don’t hesitate to follow up here or with an email to email@example.com.