Over the past 2 years I have exchanged emails with Ambient (and occasionally directly with Fine Offset) about bugs. This was not a continuous conversation, but in spurts. I figured I'd do all of us a favor of collecting all bugs and issues that I know of in one place, so here goes (hope I did not forget anything):
Bugs: Time and timing related- Realtime updates to Wunderground are attempted, even if no station is configured. Even if stationID or password were left empty, and therefore a request to WU could never succeed, the attempt was made nonetheless. Due to the failing request, retries are attempted every 2 seconds. Request plus fail response consume about 0.5KB and doing this every two seconds means 43,200 times a day, using 21MB each day. This is all wasted bandwidth and unwanted consumption, particularly important to those of us on slow or capped connections, and not using WU. This issue has been fixed in firmware 3.1.6 where no uploads are attempted if stationID or password are empty.
- When publishing sensor data to WU, the rapid-fire API is used with a parameter of "rtfreq=5", indicating updates every 5 seconds. The reality, see above, is more like 30 seconds. The parameter should reflect the programmed interval.
- I know the reporting interval has changed over various firmware versions, so if you are running an older version, you may see a different interval.
- The very first/many publishings of sensor data to WU may have an incorrect date/time. This is due to the ObserverIP setting its own internal clock based on the response from WU. Right after a reboot/power reset it is likely to not have the correct time (for me it is usually early Jan 1 of 2000) and will include an incorrect time stamp until it successfully takes the time from a WU response.
- Needless to say this can cause the data to be discarded by WU because its timestamp is nonsensical.
- MeteoBridge/WeatherBridge are not affected by this as they are better time keepers
- The delay to get the right time is not just until one successful response is received. I waited for 5 minutes and saw many success responses from WU, yet the time was still not correct. S power-reset does force this to happen sooner, but I have not been able to find consistent behavior!
- When changing units in the station settings page, it may take 3-5 updates of the LiveData screen before the new units are reflected. This may be just an inconvenience for users that do not use MeteoBridge, but can be a real problem otherwise.
- Over time the response time of the LiveData page seems to become progressively slower. This is not 100% consistent in terms of how long it takes before it becomes noticeable.
Bugs: Sensor value related- When using the rapid-fire API, some sensor values are reported to WU as values with two decimal places. Yet the LiveData page displays only one decimal. Products like MeteoBridge, and WeatherBrige get values from the ObserverIP by scraping the LiveData page, and they loose that precision. May be not so important, but it sure is inconsistent.
- Internal storage/calculations for temperature are limited to an accuracy of 0.1C, equivalent to 0.0555F. Yet you will not see F values with a second decimal in the live page.
- All temperatures measured in C are converted to F using a formula that computes only one decimal. It is equivalent to computing more decimals, adding 0.05, and then truncation to one decimal. 20C is in theory 68.00F, and is reported as 68.0F (good), but 20.1C is in theory 68.18F, but reported as 68.2F (not good, 0.02 error), 20.2F is in theory 68.36F, reported as 68.4F (0.04F error). Consequently this can result in errors up to 0.05F. Noteworthy, but likely irrelevant.
- Indoor and outdoor temperatures are reported to the rapid-fire API, as well as the LiveData page using only one decimal, so data between the two is consistent, but subject to the stated error.
- Error is not the same as accuracy. Due to the above, you will never see certain F values and, generally neighboring values are 0.2F apart. The stated accuracy in the spec-sheet is 0.1F.
- Wind speed and gust speed is reported to rapid-Fire with two decimals, but we have only one decimal in the LiveData page. One example is a measured wind speed of 2.7 m/s, in theory 6.03970 mph, reported wind speed is 6.04 mph (rapid-fire), but shown as 6.0mph in LiveData. As far as I can tell, the values converted from m/s are correctly rounded to two decimals (unlike the rounding for temperature). The maximum observed error I have seen is close to 0.05 mph, so the last digit of two is not all that reliable. The specified resolution is 0.1mph when, in fact it is 0.1m/s which amounts to 0.045mph, which is twice as good as stated on the spec.
- I have not researched in as much detail, but pressure is measured in hPa and converted to whatever you had configured. Specified resolution is 0.01 inHg, which amounts to .339 hPa. The spec sheet on the fosh.com site lists 0.08 inHg (or 2.71 hPa) instead (very different, same hardware). I suspect, but have no evidence, that the real value is 0.25hPa, which corresponds to 0.0074 inHg. This is reported to rapid-fire with two decimals (for inHg), and shows in LiveData with two decimals as well. When reporting in mbar (LiveData only, rapid-fire always gets inHg), it still shows two decimals, but the second one is always 0. Since I see various decimal fractions for hPa displays, I conclude that true resolution is sub 1hPa (0.03 inHg).
- Some users have reported "missing values" for the internal pressure sensor. These are visible as gaps in the pressure graph on WU. In particular these issues have been reported since WU changed to a new server farm using Amazon AWS. This has been attributed (by Ambient) to the new servers being noticably slower than the old situation and a timeout occurring in the ObserverIP causing the internal sensor unit to not be serviced on time. Subsequent firmware updates attempted to solve the problem by increasing the timeout values (3.1.6 is the first one that supposedly really fixes this, see above). This appears to have mostly alleviated the problem, but as has been explained to Ambient, this is not a good/great solution because while the OIP waits for a timeout to occur, nothing else is serviced, including web pages (see MeteoBridge). A better solution, with technical detail, has been supplied to Ambient/Fine Offset, but so far has not been implemented, nor is there promise to improve this.
- It has also been suggested that this can be due to placement of the indoor sensor unit, in particular if it is too far from the OIP. It is my opinion that if the unit is too far away it would show as trouble with all sensors in the unit simultaneously, and not just pressure, but I may be wrong. What constitutes too far depends not only on distance, but radio frequency transmission characteristics and obstructions in your particular situation. In my case 30 feet and one wall in between seems to be just fine.
Bugs: UI- Values entered on the calibration page or not always echoed back after submitting. There are sometimes subtle changes that are confusing. See discussion below.
- While it is possible to change the WU stationID/password values in the "Weather Network" tab, it is not possible to completely remove them. Inputting an empty field for either results in an error message. Yet there are cases where this exactly what one wants to do (see introduction above). Currently the only way is to reset to factory defaults, which means all units and calibration values have to be re-entered. This is at the very least cumbersome, and good luck if you forgot to note them down first.
Bugs: Network relatedMuch of what I discuss here can only be observed by "packet sniffing" on the network, or sometimes indirectly if you are measuring data usage.
- It appears that the TCP network software stack in the ObserverIP produces 5-8 retransmits of the upload request to WU each time an attempt is made to upload. I have not done sufficient analysis to determine what the exact reason for the retransmit is. I have simulated the very same upload request using "curl" on my desktop Mac and observed none of the re-transmits. The only real difference in these scenarios is the TCP/IP network stack, which is why I suspect the ObserverIIP.
- The ObserverIP does not implement an NTP (Network Time Protocol) client. If it were it would not have to rely on getting the time from WU. This is important because some users, like myself, do not wish to configure a stationID and thus no calls to WU would be made. In such scenarios the unit's internal time would always be incorrect.
- I have suggested that an NTP client function be implemented. It would also be good to allow the user to configure which NTP server to use, but a suitable default might suffice. This does not have to be a full blow client (that would smoothly manipulate the system clock to avoid sudden jumps and discontinuities). A simple client, executed once every so often to set to the correct time would likely do a sufficient job. How often would be determined by the drift characteristics of the internal clock (unknown to me), but I suspect once a day might be enough, so it would not be a lot of network overhead. It would also fix the issue of incorrect timestamps on initial contact with WU.
- An alternative work-around that I have suggested is to not require that the response from WU is successful before extracting the time from it. Even an "invalid password" response carries the time header, so it could be used. This would allow a user such as myself to configure a bogus stationID and still get time updates. The downside would be that this call is now made every 30 seconds again, wasting lots of data per day, which could be hurtful to users on slow speed or capped connections. You might ask why not simply upload directly from the ObserverIP to WU. I will answer that in the "Observations" section.
Issues/Observations- If/when station is correctly configured, uploads to WU appear to happen about once every 30 seconds, which is less than stated on the product specifications: "14 second real-time updates on the ObserverIP and the internet". It also does appear to be different from the update frequency of the LiveData page.
- The calibration page offers input fields so the user can enter corrective values for various sensors. It is very hard to use this page for several reasons:
- Each input field states acceptable range multiple times for different units. The user must remember what units were set in the station settings page so as to know what the correct value/range is to use here. It would be much, much better, if this page only display the range for the currently selected units.
- Likewise it would be much better if the LiveData page would show the units with each value.
- Due to the formulas used for conversion from the internal storage units (which I suspect to be temp in C, pressure in hPa, wind in m/s, humidity in integer percent) to the display units, and back from inputted values to internal storage, truncation and rounding errors happen. See also remarks above about sensor value issues. The back and forth conversion exacerbates the problem beyond the one for sensor values. As a result it is possible to input values that are inside the stated range, within the stated resolution, yet when submitted a slightly different value is echoed back. It is not clear to the user if the displayed value is the one actually being applied (I am pretty sure sometimes it is not). It is also sometimes possible to enter a slightly higher value than desired, only to have the re-displayed value to be the one desired. Uncertainty still exists though.
- For example an offset entered as 0.1F becomes 0C stored after truncation, and therefore 0F after display. 0.2F as input becomes 0.1C stored after truncation and therefore 0.1F for display. Yet 0.3F becomes 0.1C stored, thus 0.1F on display and 0.4F becomes 0.2C stored, and 0.3F on display. You’ll find that this formula accounts for all the displayed offsets you may encounter. It seem fairly obvious that the above is a problem for any user who chooses to work in units of F because effectively they cannot enter any offsets such as 0.2, 0.4 etc. Yet, according to the product specification sheet, the temp resolution is 0.1F
- There is also a user interface problem. When I enter a desired temp offset of 0.4 the resulting display is 0.3, as explained above. If I now go back to try and input 0.3, the resulting display is 0.3, which is inconsistent with the above, because I should have gotten 0.1. I believe this because of a misplaced optimization where nothing is done if it appears the user did not actually make a change. This is further confirmed if I enter 0.31 instead. Textually this differs from 0.3 and so the optimization does not kick in, calculations are done, and the result is as expected because 0.31 would convert to 0.1C (stored) and thus 0.1F displayed. The 0.3 should have been treated as if it was a completely fresh input and resulted in 0.1. Of course the optimization would be valid if the problem with rounding/truncating sketched above would not exist.
- Next I set my units to F and since I had originally entered a -0.4F offset, it had been displayed as -0.3F temperature offset. I then changed units to C and went back to the calibration page. The offset was now displayed as -0.2. This is consistent with the discovery above because the -0.4F would have become -0.2C stored. When the units were changed, the value of -0.2 showed (no further conversion needed). Changing the units back to F shows -0.3 again, but of course the intended -0.4F is gone forever.
From the observed behavior it also appears that calibration values are stored as strings, or fixed point numbers with only one decimal. It should be considered to store them with more precision, and still display them rounded.
- On the LiveData screen battery status for indoor and outdoor are shown as both hexadecimal values and textual labels. Even when batteries are good, my unit consistently displays "0x69/LOW STATUS" for indoor and "0x65/Normal" for outdoor. In particular the "LOW STATUS" is alarming to the user. Inspection of the indoor unit's display does not reveal the low battery indicator there so this interpretation of the hex value seems in error and unnecessarily alarming, or certainly unhelpful. In addition, the possible values and labels are not documented as far as I can tell
- The "Local Network" page has a setting for "Server Listening Port" with a default value of 5000. This is completely undocumented and certainly does not correspond to the web server port, which is the default port 80. I suspect this has something to do with the ObserverIP hardware being able to act as two virtual serial ports over Ethernet (presumably over this port), where each serial port would be an interface to the radio dealing with indoor and outdoor unit. Having access to these serial ports can be potentially very useful to products like MeteoBridge (see below), and should either be documented, or the setting should be completely removed to avoid confusion. It may also require commands to be removed from the interface available via telnet.
- Why not report directly to the WU? It has been my experience during calibration of my Ambient WS-1400-IP that the calibration method offered by the calibration page (offset only) is unsufficient. I found that I would get better results if I could apply a linear correction (offset plus slope). The ObserverIP is not capable of this, but in my case MeteoBridge is. The same might be true for other "external" solutions. The other issue is that I (and many others) not only report to WU. I, for example, also report to CWOP and MADIS. Surely one would not want to report different values to WU than to CWOP. This can be more or less guaranteed if you let all uploading be handled by MeteoBridge, but that requires you shut off the uploading directly from WU.
Such uploading, while useful for more casual users of the product, is not good for more serious users. - What about this calibration? I used a linear correction with clamping (to make sure values stay in range). So to implement this in the ObserverIP would complicate the UI quite a bit, and I am not advocating it. If you are sophisticated enough to want this kind of correction, you probably also wants something like MeteoBridge.
MeteoBrige/WeatherBridgeThis is, as far as I know, identical hardware, and basically identical software, except for branding, and perhaps different versions. Caveat is that I don't have a WeatherBridge (it is several times more expensive than buying a TP-LINK TL-MR3020 and licensing MeteoBridge for it), so I am guessing here.
The manner in which both get information from the ObserverIP is to act as a web browser and request the LiveData page. Values are then "scraped" from this page. In order to get the interpretation of the values right, the station settings page is also "scraped" to determine the unit. I am not sure if the latter is scraped each time before the former is.
A possible issue exists here with respect to the delay in LiveData reflecting newly selected units. The 3-5 screen delay (around 1 minute) before new units show up create the possibility that MeteoBridge misinterprets 2-4 screens. In real life this depends on when exactly the MB calls up the LiveData page, and how frequently. I would say it is somewhat likely, but you are probably not changing the settings much, so practical impact may be low. It might be even less of an issue if MB realizes that the converted values appear abnormal and ignores them. Still, it is a problem that would not exist if the LiveData page would always use the current units.
The slower and slower responses from the LiveData page can become a problem for MeteoBridge resulting in sensor values of "--". Only a reboot of the ObserverIP seems to solve this.
The method whereby MB has to screen-scrape web pages from the ObserverIP is extremely cumbersome and potentially error prone. It also wastes bandwidth although this is likely not significant for an in-home network. It would be much, much better, if there was a JSON-API endpoint that would deliver all sensor values, and their units, in JSON format, in a single go. This should not at all be hard to create. Alternatively, documenting the serial port over Ethernet protocol and the packet format from the radios, would allow MB and others to do their own direct interpretation of the sensor values. Even better would be the inclusion of a reliable timestamp in the response, where the timestamp would correspond to when the sensors were read out. If an external application such as MB reads data too often, the timestamp would be the same in subsequent calls, and duplicate data could be avoided.
MB should be receiving the higher decimal precision that is provided to WU. This can be done either by making sure that the LiveData page uses the same precision, or (in addition) in an API implementation.
Final NotesIf anybody knows of any other bugs or issues, you can PM them to me and I can edit this post to stay up to date.