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 '^]'.
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
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
- 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
- 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
(0.0.0.0, indicating anything). There doesn't seem to be any IPv6
- 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,
- 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 ),
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.