[Back to the Floodgap main page] Back to Floodgap Department of Hacking

Hacking the Ambient Weather ObserverIP @ Floodgap Department of Hacking

I like weather here at Floodgap. I like using it as a sensor array to help automate lighting and climate control as the conditions dictate, and a big part of that is using the ObserverIP for my inexpensive but decent Ambient weather station, which I like as well. Here's some tips so you'll like it too.

Last update 6 September 2020.


The ObserverIP module is a small network device based on an ASIX microcontroller (probably the 100MHz RISC AX11025) implementing the Intel 8051/Dallas 80390 instruction set. The microcontroller contains the Ethernet PHY, flash, RAM and TCP/IP acceleration, and interfaces with the onboard radio receiver to obtain data from the indoor and outdoor sensors. It is compatible with the WS-1000 array (used in the WS-1200, WS-1400, WS-1000-WiFi and WS-1001-WiFi packages). This array transmits at 915MHz with about a 300' maximum range via line of sight, though Ambient says in practice this is about 100' under normal conditions. The unit here at Floodgap has a regular Ethernet PHY but WiFi versions are available.

Ostensibly the ObserverIP's only purpose is to take data from the sensor arrays and send it on to WeatherUnderground and/or Ambient's own weather service, which is configured through the built-in web server interface. As there is no local storage on the ObIP other than its built-in flash memory, this is not surprising.

Networking and Configuration

The ObserverIP obtains its initial address when brought up cold from a factory reset nominally from either DHCP or BOOTP, and firmware updates are also sent over BOOTP and TFTP (the software Ambient Weather provides actually implements a miniature BOOTP and TFTP server). If you're using the ObIP with an unsupported OS, such as a Power Mac or other system, you'll need to get a system running these services to successfully send updates to the ObIP (see the tftpserv, filename and dlfirmware commands below). This page assumes you are running at least firmware 2.1.0.

Once an initial address is configured, most basic configuration with the exception of firmware updates can be done from the ObserverIP's web interface (just connect to it with a web browser to that address), including setting the desired final network address.


The ObIP doesn't support talking to services other than WU or Ambient, but if you implement a server with the right API, it can accept data from your device. The only endpoint that needs to be supported is a webserver that answers to /weatherstation/updateweatherstation.php (the fields it sends are self-explanatory). This doesn't need to be a PHP script, by the way; it just has to answer to that URL (my local weather logger is written in Perl). The entirety of the arguments are passed via HTTP GET, making it particularly easy to process. Note that it also passes the station ID and password in cleartext, so don't set these to anything meaningful if you have to traverse a public network! (They're set under the Weather Network tab in the web interface.)

To make the ObIP talk to that server either involves the setdsthn command (explained below), or simply forge a DNS entry for rtupdate.wunderground.com using dnsmasq or a similar utility, and have the ObIP use that for DNS resolution.

Here's how I organize what my station reports on the gopher server. I don't ingest all of the fields it provides since I don't routinely use them.


The ObIP, however, has a back door which allows additional configuration options the Web interface doesn't expose. If you connect to it over Telnet, you'll get a prompt, and assuming no one has changed the defaults, you can log in:

% telnet thebox
Connected to thebox.
Escape character is '^]'.
username: admin
password: admin (not shown)
Successful login through telnet

Confusingly, the Telnet prompt you see is actually the Telnet prompt from the ObserverIP, not from /usr/bin/telnet.

For most of these commands, if you omit the argument, it will show you the current value of the setting. For most settings to stick, you should follow the changes with a saveconfig (and maybe a reboot to make sure).

Displays this somewhat helpful list, but without all this helpful annotation.
Reboots. C'mon, do I have to spell this out?
Usage: passwd
Sets the administrator password in the same way as your typical shell prompt:
       Old Password:
       New Password:
       Re-enter New Password:
Usage: username <user name>
Sets the administrator username (default admin).

Usage: ipconfig
Usage: setip <ip addr>
Usage: setmask <netmask>
Usage: setgateway <ip addr>
Usage: setdns <ip addr>
Displays and configures the IP, netmask, gateway and DNS. Enter setdns by itself to display the nameserver (it does not show in ipconfig). These are for static configuration only: if your ObIP is obtaining its network information over DHCP (the default), any values you set this way (except, possibly, setdns) will be ignored and any values the subcommands display will not reflect the current state of the device (use ipconfig).

Usage: setmode <mode>
       <mode>: 0: SERVER     1: CLIENT
Usage: setsrvport <port>
Usage: setdstport <port>
Sets push (client) or pull (server) status. If set to client (the default), the ObIP pushes data to a WU-compatible endpoint whenever the data from the weather array changes. This is almost always what you want. If set to server (pull) mode, then your application should connect to the designated port to obtain weather data. I haven't experimented with this mode since operating as a push client is much more efficient. The default port is 5000.

Usage: dhcpclient <status>
       <status>: 0: disable     1: enable
Enables/disables the built-in DHCP client (default is on). ipconfig will display the address that the DHCP lease is for, which may be different from setip.
Usage: connectype <protocol>
       <protocol>: 0: TCP     1: UDP
Selects TCP or UDP (default is TCP, almost always what you want).
Usage: transmitimer <time>
       <time>: time in ms
In client mode (the default), how long to wait for transmission to complete (default is 100ms).
Usage: saveconfig
Saves the configuration. This isn't necessary for every command but is a good idea.

Usage: accessip <index> <ip addr>
       <index>:   index of accessible IP
       <ip addr>: accessible IP address
Usage: setaccip <mode>
       <mode>:  0: disable    1: enable
Configures the IP whitelist. Use accessip to populate the list by index and then setaccip to enable the whitelist globally (default is disabled). A single entry is populated in the IP whitelist by default (, indicating anything). There doesn't seem to be any IPv6 support.

Usage: setaw <cold start> <authentication fail> <ip changed> <password changed>
       <cold start>:             0: Disable     1: Enable
       <authentication fail>:    0: Disable     1: Enable
       <ip changed>:             0: Disable     1: Enable
       <password changed>:       0: Disable     1: Enable
Configures automatic warnings when certain events occur (presumably to the server port, if enabled). By default, no warnings are turned on.

Usage: setdsthn <Host name/IP>
Sets the hostname or IP address of the server to send updates to (in client mode). This is the simplest means of redirecting the ObIP to send its data to your server rather than WU.

Usage: tftpsrv <ip addr>
Usage: filename <file name>
Usage: dlfirmware
Configures the TFTP server and filename the device will request to obtain firmware (and dlfirmware kicks off the process). By default this points to what the official firmware updater will serve it over BOOTP. If you change these options and you have an OS supported by the Ambient updater application, note what they were before and set them back to the default values afterwards or Ambient's updater may no longer be able to push firmware to it.

Usage: seteep <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N>
With no arguments dumps the contents of the EEPROM, and (with arguments) allows you to set any number of contiguous bytes using the first argument as an offset. Values are in hexadecimal. Although I see what looks like some network address values in there, I don't know what bytes correspond to what.

Usage: dbgmsg <mode>
       <mode>: 0: Disable    1: Enable
Configures whether debug messages are turned on (default, surprisingly, is to enable). In normal operation I don't see much in the way of these messages, though.
Usage: connstatus
Shows whether the sensors are connected, which is typically the case.
Usage: ping xxx.xxx.xxx.xxx
Pings another host on the network. Timeout is a little slow, and this command isn't all that helpful if you're already connected to it over Telnet since clearly it's already got connectivity!

Usage: setRTC <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N>
This is actually setrtc, not setRTC. Like seteep, with no arguments this displays the current values of the real-time clock, and allows you to set any number of contiguous bytes using the first argument as an offset. The RTC block is 63 bytes in length but only the first seven bytes seem to be relevant. In order, they are (in hexadecimal, but they're encoded as BCD) seconds, minutes, hours (with bit 3 set, so 84 is 4am, 97 is 5pm [1700 hours] and a1 is 9pm [2100]), a gap byte of unknown meaning, the day, month and 2-digit year. This is usually set by the receiver. The time is in UTC.

Questions or comments?

If you know a little more about some of these options, drop me a line.

Cameron Kaiser