Author Topic: ObserverIP Firmware Tips - WS-2902A WS-2000 + Dealing with Meteobridge Bad Data  (Read 1218 times)

0 Members and 1 Guest are viewing this topic.

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
PURPOSE: To list out and label each previous ObserverIP firmware (and current one) as to which are good downgrade choices and which aren’t. How to best run an ObserverIP as an add-on for WS-2902A and WS-2000 stations.

BONUS: How to Set Meteobridge Alerts and Automated Restart for Bad Data. (Info is few posts down, or follow this link):
https://www.wxforum.net/index.php?topic=34948.msg357305#msg357305

DISCLAIMER: This post is to share my experience with the ObserverIP in use with the WS-2902A sensor array. Please provide your feedback to this thread so that we can collaborate and learn from each other. My focus will be on this combination of devices. If you use an ObserverIP with a different sensor array like a WS-1400-IP or a WS-0900-IP then I would suggest that you read the ObserverIP firmware notes, and ignore my  notes. The focus will be on testing the best firmware for the WS-2902A for use with a Meteobridge. I mean why else would you need an ObserverIP if not for a Meteobridge as the ObserverIP alone hardly provides and added capabilities to the WS-2902A display console. From my testing it seems that the display console does a better job than the ObserverIP for WU and ambientweather.net.
https://www.wxforum.net/index.php?topic=34976.0

The purpose of this is to help others with WS-2902A and ObserverIP decide on which firmware to use. Given that new firmware is released often, this is information that can quickly become outdated. But at least it could serve as a guide in case someone wants to downgrade from a future new release and they need help deciding which previous firmware was a good one and which was bad. There may be a suitable older firmware for your needs as some updates are done for others models. But eventually there might be a feature you need that you can’t do without, so you’ll have your own minimum version that you are willing to use.

Currently with a couple of the latest firmware version for the ObserverIP I’ve noticed some stability problems where the ObserverIP will loose all network connectivity, become unreachable via the network, and it turns off the RF, Indoor, Outdoor, and Server LEDs. Only the ACT (blinks), Link, and Power remain on (yet is unreachable via network). This seems to happen randomly. I’ve read reports from other users having the same problem.

Turns out that perhaps we are asking too much from the ObserverIP. At least that is what is written in the firmware notes since version 4.3.8 release. Basically the firmware notes state that the ObserverIP was not designed to be access by many devices at the same time. It can supposedly reliably service one request at a time, meaning one Meteobride or one web browser looking at Live Data but not both…as they could overlap. The firmware notes also mention not more than 4 simultaneous web page requests. So it mentions 1 simultaneous request and it also mentions 4 simultaneous requests...which makes it vague and unclear which it is. From my experience I think 1 request is taxing enough.

Here below is my list of which ObserverIP firmwares are the Good Ones and which are the Bad Ones.

The Good Ones –  ObserverIP firmwares for use with WS-2902A:
These all seem to have 30 secs for WU updates. - I recommend using the console for WU.
4.4.9 - Latest build. Fixes for those that have changed rain calibration to anything other than 1.0. (still has DHCP bug)
4.4.7 – Came out to fix problem with WS-0900-IP
4.4.6 – Issued to fix problem with WU and WS-0900-IP, this fix did not impact WS-2902A
4.4.5 – Issued for adding more sensors (up to 8 sensors)
4.4.4 – Fixes WU reboot loop that was introduced by 4.4.2 - (So this reboot issue is not present in 4.4.0)
4.4.0 – Has fix for time stamp introduced by 4.3.8, First good one to have lockup fixes.

The Bad Ones – ObserverIP firmwares you should avoid with WS-2902A:
4.4.2 – Has a reboot loop issue
4.4.1 – Has WU bug
4.3.8 – Has time stamp bug. Was the first one to address and make some fixes for lockup issue of multiple devices accessing and is the one with notes about the hardware limitations of the ObserverIP. Not recommended because of time stamp bug.
4.2.0 – Has unspecified bug
4.1.9 – Has unspecified bug

The Not Great but maybe Just Okay Ones (a bit dated) – ObserverIP firmwares for WS-2902A:
These just were around before addressing Meteobridge Live Data access, may be slow, may lock up.
4.3.6 – Improved WU upload stability
4.3.1 – Removed Telnet
4.2.1 – The last probably okay one to use with Telnet – Only needed if you use WeeWx redirection or the like. Fixes bug in 4.2.0.
4.1.8 – Supposedly has 14 second WU updates. Prior to this since 4.1.0 timer for WU was 60 secs.
4.1.7m – no info
4.1.7 – Fixes WU formatting error when reading data string…may have affected Meteobridge.
4.1.4 – First one to support WS-2902A as a WS-1600-IP

Anything older than 4.1.4 is not a concern because it is not compatible with the WS-2902A (as a WS-1600-IP). There technically was a hack way to make older firmware work with the WS-2902A by selecting WS-1400-IP and then doing some correction to the anemometer because the WS-1400-IP counts wind differently. But again the WS-2902A has been supported by some time and there are plenty of newer firmwares to pick from that are probably better.

Link to all of these firmwares:
https://p10.secure.hostingprod.com/@site.ambientweatherstore.com/ssl/iptools/

TIP: If you want a Meteobridge and you also want to do redirection over to WeeWx then an option is to have 2 ObserverIP devices. One with the best firmware for the Meteobridge and one with the best 4.2.1 for WeeWx with Telnet capability to do the redirection. You will only need one WS-1000-BTH.

« Last Edit: October 23, 2018, 06:02:37 PM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #1 on: August 21, 2018, 05:04:56 PM »
After a bit over 24 hours of not touching my ObserverIP running 4.4.7 locked up. Only Power, Link, and ACT lights on...yet not able to be pinged on network and GUI doesn't come up. It stopped reporting to both WU and ambientweather.net. I suspect the problem may be related to either uploading to WU or ambientweather.net with the ObserverIP. Even though I suspect the problem to be WU I'm going to remove ambientweather.net from the ObserverIP as a test. If that doesn't work then I'll disable WU. The best method to remove a service upload is to first do a factory reset and then not configure that option. I've read that in the past some firmware kept reporting even after deleting the configuration fields.

So no browser access was done to Live Data page. Only the Meteobridge v3.7 was accessing the ObserverIP when lockup occurred.

Really wish Ambient (Fine Offset) would come out with a better ObserverIP. I'd pay more money for it. But it would need to be compatible from a Meteobridge perspective. Perhaps the data scraping isn't the best method. They should add a direct upload to Meteobridge option and then Meteobridge should adopt the new method. It's about time.

WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline VinnyRI

  • Member
  • *
  • Posts: 40
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #2 on: August 21, 2018, 06:47:33 PM »
After a bit over 24 hours of not touching my ObserverIP running 4.4.7 locked up. Only Power, Link, and ACT lights on...yet not able to be pinged on network and GUI doesn't come up. It stopped reporting to both WU and ambientweather.net. I suspect the problem may be related to either uploading to WU or ambientweather.net with the ObserverIP. Even though I suspect the problem to be WU I'm going to remove ambientweather.net from the ObserverIP as a test. If that doesn't work then I'll disable WU. The best method to remove a service upload is to first do a factory reset and then not configure that option. I've read that in the past some firmware kept reporting even after deleting the configuration fields.

So no browser access was done to Live Data page. Only the Meteobridge v3.7 was accessing the ObserverIP when lockup occurred.

Really wish Ambient (Fine Offset) would come out with a better ObserverIP. I'd pay more money for it. But it would need to be compatible from a Meteobridge perspective. Perhaps the data scraping isn't the best method. They should add a direct upload to Meteobridge option and then Meteobridge should adopt the new method. It's about time.

Why don't you just let meteobridge do all the weather site uploads?

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #3 on: August 21, 2018, 08:21:39 PM »
I am currently running a temporary test comparing 3 devices simultaneously uploading to WU to different station IDs. All 3 devices data originates from the same WS-2902A outdoor sensor array.

1. WS-2902A console --> WU
2. ObserverIP --> WU
3. Meteobridge --> WU

So to answer your question as to why I don't just let the Meteobridge do all the uploading I'll say this... From a brief analysis of all 3 devices the data looks worse coming from the Meteobridge. Same data, just seeing various issues. These are only WU issues with the Meteobridge as the Meteobridge is performing well with other services. I just got my Meteobridge. So I need some more data to have more details. I'll be back with a nice long post showing screenshots and giving examples and explanations. It won't be on this thread. I'll create a new thread as I want more exposure and attention to the matter. Look for it soon in the Meteobridge sub-forum on this website. I'll try and remember to post a link though on this thread.

UPDATE - Not a Meteobridge issue. Look for update in this Ambient Weather sub-forum.
« Last Edit: August 25, 2018, 11:48:13 AM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #4 on: August 25, 2018, 12:24:55 PM »

Why don't you just let meteobridge do all the weather site uploads?

I've posted an new topic with analysis as to why I dislike using the Meteobridge for posting to WU specifically, (But it is because of the Ambient Weather ObserverIP).

https://www.wxforum.net/index.php?topic=34976.0
« Last Edit: August 25, 2018, 04:40:00 PM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #5 on: August 25, 2018, 04:10:32 PM »
Well both my ObserverIP (4.4.7) and Meteobridge (3.7) locked up today. Yes both of them. But this time the ObserverIP was still connected and all the blue lights were on.

I tried to go to the ObserverIP's configuration browser pages and none of them would fully load. Not just that the Live Data page wouldn't load but none of the other configuration pages would either. I just got the background and one time the logo showed up but it was pretty much locked up and 95% unresponsive.

Without yet touching my locked up ObserverIP I decided to look at the Meteobridge's status. To my surprise it was locked up too. It would load pages very slowly and not responding sometimes. I think even what I saw was probably just browser cached. The Live Data page and the Weather Network page wouldn't load at all. I could get the network page up and so I restarted the Meteobridge by pressing the awkwardly named "Save and Apply and Reboot" button. It should just be called "Save, Apply and Reboot." I should have left the Meteobridge alone and then seen if just an ObserverIP reboot would have fixed the Meteobridge. But unfortunately I restarted both of them. Next time I'll just restart the ObserverIP and see if the Meteobridge recovers by itself.

Interestingly enough the ObserverIP which was only publishing to Weather Underground, (I had turned off ambientweather.net), kept uploading just fine even while its web server pages were all locked up. I looked at the WU data and it was all there, all 1 and half hours during lockup. But looking at other web services that the Meteobridge was configured to upload to had stopped (CWOP, AWEKAS, PWS).

This tells me the ObserverIP lockup caused the Meteobridge to lockup because it couldn't read data. Shame that the Meteobridge also becomes unresponsive though. I really should have left the Meteobride alone to see if it recovered..oh well...next time.

I want to find the culprit and see if I can alleviate the load on the ObserverIP. Two solutions come to mind.
1. Configure the ObserverIP to not upload to WU (it already was not uploading to ambientweather.net). This might lessen the load on the ObserverIP.
...Or...
2. Configure the Meteobridge to not upload to WU but leave it uploading to other services. Considering that I just finished testing my comparison of uploading to WU via all 3 devices and determining that I didn't like the Meteobridge for WU, I decided to remove this function rather than the previous #1 option I listed. This might lessen the load of the ObserverIP as the Meteobridge doesn't have to try and read the ObserverIP Live Data every 5 seconds like it was trying to do before. Now the Meteobridge just needs to read every 5 minutes for CWOP and AWEKAS and every 10 minutes for PWS.

So we will see how it goes. I have I feeling I might have to also do my Option #1 above. And there really isn't a good reason why the ObserverIP should need to upload to WU since I already know that I prefer uploading to WU with the WS-2902A as mentioned in my other thread.
https://www.wxforum.net/index.php?topic=34976.0

But I've kept the ObserverIP uploading to WU because every good scientist knows you only change one variable at a time or you don't get to find out what the real culprit is. I don't just want to solve the problem, I want to understand what and why.

I really wish Ambient Weather would release a newer ObserverIP. They need to come out with Version 2.0 with more powerful CPU other stuff like perhaps having a better connection to the Meteobridge than having to data scrape a web page. I suppose most of this requires Fine Offset to actually do this.

The best part of all this I realized is that by having the WS-2902A display console upload to WU that didn't skip a beat. I also have my WS-2902A display console uploading to ambientweather.net, WeatherCloud, and WOW Met Office. The WS-2902A display console is performing like a champ. Too bad it doesn't have a way to connect to the Meteobridge. I can't wait to test the WS-2000 display console and see what functionalities that holds.
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline sjbauer

  • Member
  • *
  • Posts: 8
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #6 on: August 25, 2018, 04:57:28 PM »
Are you planning on testing the observerip with the other non ambient firmware?  Aercus firmware which can send the data directly to weeex or a meteobridge?



Sent from my Moto G (5) Plus using Tapatalk

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #7 on: August 25, 2018, 09:00:28 PM »
Are you planning on testing the observerip with the other non ambient firmware?  Aercus firmware which can send the data directly to weeex or a meteobridge?


I am planning on testing the ObserverIP with the last Ambient firmware that allowed Telnet (version 4.2.1) and redirecting WU to whatever IP address you want (your WeeWx server). But I probably will not be ready to do that for a few weeks or more as I want to fully test Ambient firmware reliability first and figure out how to best keep the ObserverIP running with a Meteobridge.

I never considered testing with Aercus firmware until just now that you mentioned it. I hardly know anything about the Aercus firmware versions or where to get them nor which version to use...etc. About the only thing I know of Aercus firmware is that I read that it will run on the ObserverIP but that the frequency will still be 915MHz in my case, so the firmware seems to not care that the frequency is different (from what I read). Likewise anyone loading Ambient firmware on an Aercus will also keep their 433 MHz...so that works too (from what I've read).

If anyone has any feedback on Aercus firmware versions please feel free to add that to this thread. I'm wondering what the pros and cons are to running either Ambient or Aercus now that you bring this up. I can think of one con and that is that with Aercus firmware you wont have the ability to upload to ambientweather.net. But I have that turned off for now in testing to eliminate lockups. But that is something that may be important to some people. I suppose with an WS-2902A display console though they can still upload to ambientweather.net.


« Last Edit: August 25, 2018, 09:02:24 PM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Re: ObserverIP Firmware List for use with WS-2902A
« Reply #8 on: August 25, 2018, 09:48:45 PM »
Here is a good way to be alerted if your ObserverIP has locked up. The Meteobridge can be configured to email you alerts if the data it is getting is bad, like when the ObserverIP is locked up.

How configure your Meteobridge to email you alerts when the ObserverIP locks up
(Scroll down to Extra section on this post to see how to automate ObserverIP restart)

If this ends up helping you, drop a note and let me know. Either in this thread or private.

1. The first thing you'll need is an email account that allows sending email via SMTP protocol. I didn't want to reduce the security in my Gmail to allow outbound SMTP emails so I used my Yahoo email address as the sender account which is my email account that I typically use for non-important stuff. I've had this Yahoo email account for a long time and I can't remember if I had to do anything to enable SMTP (outbound email via your own email client). So you may need to look that up on how to allow your email account to be allowed to send SMTP emails.

2. Then on your Meteobridge you first need to configure under Services tab your email account settings. This is the email account that the Meteobridge will use to send out alerts. Fill in all the Email fields. See attached screenshot. Press the Save button. Be sure then hit the Test Email button and see if you get the test emails. Check Spam folder to see if test alert ended there. I tried receiving the alerts to a Hotmail address and it goes Spam every time so that is no good. That is why I used my Gmail address as the recipient of these alerts, which is totally fine and does not compromise your Gmail. So Yahoo sends and Gmail receives the alerts.

Ignore the top Event Definition section for now. That is covered in step 3. next.
 [ You are not allowed to view attachments ]

3. The next step is to add a new Service Event Definition to the Meteobridge.
- Click drop down for Select Service and choose Email.
- Click drop down for Service Type and choose Alarm Condition.
- Click on the Add Service Event button.
- You should see the empty Event Definition box added to the top of the configuration page.
- Leave Email type as One-Time Alarm.
- Fill in the following for Raise: [mbsystem-lastgooddata] > 300 || [mbsystem-lastgooddata] == -1
- Fill in the following for Clear: [mbsystem-lastgooddata] < 30 && [mbsystem-lastgooddata] != -1
- Fill in the following for Sub#Body (the # is important): Meteobridge Alert - No Data # Meteobridge has not received data in over 5 minutes.
- Fill the email address to receive these alerts in the To-Addr.: youremail@service.com
- Click Save.
- Click Test to see if this Event Definition works.
(see attached screenshot above for Event Definition).

4. Now we need to manually trigger a real alert by simulating an ObserverIP lockup or bad data incident. Simple, just manually pull the power on the ObserverIP and wait 5 minutes. Or you can alternatively unplug the Ethernet cable on the ObserverIP for enough time to cause the trigger event. If you are testing you may want to reduce the time set from 300 to 60 seconds. I would be sure to put it back to 5 minutes when you are done testing or you might be getting insignificant alerts like when you reboot your router or you have a power brown out or if your Meteobridge is connected via WiFi it gets frequently interrupted...etc.

5. The next thing to know is that the alarm event gets automatically reset when good data resumes. Plug the power back into the ObserverIP and wait for it to power up and start giving good data to the Meteobridge. Go to the Meteobridge's Live Data tab you can monitor both the Triggered event and later by refreshing the page you can see that the alarm has been cleared and is ready to send another email if another bad data event occurs. You can do a mouse over on the orange "i" box next to Triggered Alarms: and see the data and times not just for the last alarm event but the previous ones too.
See attached screenshot for the active Triggered event (active outage) and for the Cleared updated status.

This screenshot shows the triggered alarm
 [ You are not allowed to view attachments ]

This screenshot shows the cleared alarm and on mouse over the previous alerts.
 [ You are not allowed to view attachments ]

Notes: If you want to understand the Raise: and Clear: settings here is the explanation.
The Raise field is the condition that must be met to trigger the alarm. Here we are checking the Meteobridge's internal tracking variable for the time in seconds of the last good data that was received. If this variable value is greater than 300 seconds (5 minutes) OR (that is the || symbols) if the number of seconds of the last good data is false, meaning there is no good data (that is the ==-1), then the alarm gets triggered and the email is sent.
The email will only be sent once no matter how long the bad data persists, that is until there is a reset with good data to that clears the alert.
The Clear: is the reset for the alarm status. Likewise here we are checking if we have good data within the last 30 seconds AND (that is the && symbols) that the data is good and not garbage (hence the data is NOT Equal to -1). The != means Not Equal.
The Subject and Body of the email message field is important to not forget the # symbol between the subject portion and the body. The # isn't sent...It is just an indicator that the prior part is the subject and the latter part is the body of the email. If you leave the # out, then the email alert will not contain a subject and all of the text will be in the body of the alert email sent.

Extra: If you want to take this to the next level you can integrate IFTTT with a home automation remote power plug adapter. If the alert is received then you can automate a reset of the ObserverIP power by turning it's power off via the IFTTT trigger. Then you can program a followup IFTTT trigger that turns the power on if the power is off moments later, ensuring the power is always automatically turned back on for the ObserverIP. You have now automated the reset process (less downtime) and you can still be alerted and have a log of the event and past occurrences.

IFTTT Tips: With IFTTT an email alert is actually not timely enough as IFTTT doesn't check for new email but every hour or two. So my solution is to have Gmail forward the email using a Gmail filter to match the message and then forward it to your mobile's SMS email address. You need to first verify with Gmail that the SMS forwarding address belongs to you. It sends out a one time verification. After that Gmail will let you create the forwarding filter rule. Most mobile providers have an email to SMS gateway where for example for me with AT&T it is PhoneNumber@txt.att.net. Look up your provider SMS gateway address. Now that you are receiving a Text message you can set the IFTTT trigger to match the SMS and perform the turn device Off and the check if a device is Off to turn it back On. You can use most any home automation device you want like SmartThings, Wink, Wemo, MyQ, etc. Yes the Meteobridge can send SMS messages but that requires setting up a paid service account with Messagebird.com. My Gmail forward to SMS solution is free. I've got this automated thing going and it is working greatly. At any time I can test by pulling out the Ethernet from the ObserverIP to simulate bad data. Works every time. If someone inadvertently turns off my smart power switch it turns itself back on with IFTTT. After going through all the trouble to set up forwarding from email to SMS I realized that I could have simply used the SMS gateway email address in the Meteobridge as the recipient email addrrss. Then it would have gone more direct to Text. But I kind of like having the email log as sometimes texting can be unreliable. This way I can get the email and check if the reset happened. Or rather if I get the email and I also get the Text I know the reset happened, plus you can set IFTTT to notify you that something happened and action was taken. If you just go to Text directly and it isn't received then nothing happens and you don't get to find out. So I think forwarding the SMS Text is worth the extra effort.
« Last Edit: August 27, 2018, 08:50:20 AM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
ObserverIP locked up again. Still running 4.4.7. Looks like it locks up every few days even without ever looking at Live Data with a browser. My automatic IFTTT ObserverIP power cycle routine is working perfectly. I love that this automatic IFTTT reset routine works but really wish I didn't need it.

Change made today after last lockup: Removed WU upload from ObserverIP. Had previously already removed ambientweather.net.

Meteobridge is still uploading to WU set to every 10 seconds (to different station ID). Wondering if this is causing ObserverIP to be over tasked by Meteobridge wanting to upload to WU every 10 seconds (CWOP only needs data every 5 minutes). Will let it ride like this for now as I only want to change one variable at a time. Observer IP is now just doing the minimal it can. Lets see what happens...

Next change if it locks up again is to increase Meteobridge WU upload frequency to every 30 seconds....or really probably just turn WU uploads off...I'll see. I prefer WS-2902A display console uploading to WU anyway as mentioned in other thread as to reasons why.
https://www.wxforum.net/index.php?topic=34976.0
« Last Edit: August 30, 2018, 11:11:54 AM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
ObserverIP firmware 4.4.7 has a networking bug, and presumably so does every version prior.

I found a bug in the ObserverIP firmware 4.4.7. If you use the default setting of using DHCP to obtain an IP address the ObserverIP will not properly renew its IP address lease. This causes the ObserverIP to potentially loose its network connection. I've then seen it reboot on occasions well after 20 minutes and then it grabs an IP address (the same IP but it went down in between causing a reboot.)

The immediate solution is to go to the ObserverIP and set a static address. But I highly recommend also then doing one of two things. You need to avoid IP conflicts when you set a static IP on a device. There are two ways to ensure this. You only need to do one of these (you can do both):
- The first way is to go to the router's DHCP server settings and set an IP reservation for the MAC address of the ObserverIP with the static address you decided to use.
- The second way to ensure no IP conflict is to change the DHCP scope on the router to not be the full subnet range and then directly on the ObserverIP give it a static IP address that is outside of the DHCP servers scope (but still in the same subnet). For example if you reduce the DHCP scope from 192.168.1.2 through .254 to 192.168.1.2 through .199 then you could use the 192.168.1.200 address for the ObserverIP (you also have given yourself a pool of numbers from .200 through .254 to use for other statics). When you set an IP address manually (a static) you should document it so that you remember what you have used and don't use that IP for a different device if you decide to make something else static.
I prefer to go the reservation way rather than reducing the scope. This way I have a table of reservations as documentation (but backup your configuration). Typically a reservation is used to have the DHCP server assign automatically that device that given address (it works like a static but you don't have to touch the device and the device is still configured for DHCP). But in this case the reservation is not being used to give that address automatically but rather just to pull that address away from the DHCP pool of addresses so that another device doesn't end up with it. You can do both, reduce the scope and set a reservation, and the reservation can be outside of the scope (this is what I actually really prefer to do).

I have reported this bug to Ambient Weather. I told them that it would also be helpful to display a running uptime since power-up or reboot. Most network devices display uptime.

Technical Details - Not Important to Know (Optional Reading):
In case you want to know more details on the issue.
DHCP - Dynamic Host Configuration Protocol.
When a network device requests an IP address from a DHCP server (typically your router on a home network) the device is then assigned an address and the DHCP server keeps track of this leased dynamic address. The DHCP server also has a configured setting for the lease time expiration. The purpose of the lease time is so that for old devices that are no longer on the network then those addresses can be recycled and so that you don't run out of addresses (254 total addresses on a typically configured home network - there are ways to have more than 254 devices). When the lease time is up the device is no longer allowed to keep using that address and the DHCP server will then forget about that lease and recycle the address for another device. But under normal operation a device will renew its IP lease at the half time of the lease (it keeps asking multiple times). The device asks the same DHCP server directly (not a network broadcast) to renew the IP as it is still on that network and typically the DHCP server complies and allows the renewal thereby extending the lease to the full lease time. If the lease was for 3 days then at 1.5 days the device asks for the renewal. In the case of the ObserverIP device it is NOT asking the DHCP server for renewal at the half life of the lease time, not even once and it should be repeatedly asking till the DHCP server responds (first failure of firmware 4.4.7). Typically at 3/4 of the lease time if the DHCP server has not responded then the device will issue a network wide broadcast as it did when it first joined the network for some other (any) DHCP server to respond. This is done in case the DHCP server went down and was replaced (not typical in a home environment, this is mostly for enterprise use when multiple DHCP servers are used for multiple subnets). At any case at the 3/4 lifetime of the lease the ObserverIP is also not sending a broadcast request for a new IP address (that is now two failures of firmware 4.4.7). So now the ObserverIP keeps running till the lease expires. I've seen other poorly designed network devices finally renew the IP address inappropriately only at lease expiration time. In the case of the ObserverIP with firmware 4.4.7 it doesn't renew ever, not even at lease expiration time (that is now three failures for firmware 4.4.7). Technically the ObserverIP should not be allowed to keep using that IP but it does for a bit of time (a few minutes). This goes against networking standards in many ways. Eventually the device falls of the network and looses connectivity. I'm not sure why it doesn't happen immediately, but when something is not working properly it is hard without having access to internal logs or code to review to determine why it is doing the wrong thing. The ObserverIP has a setting that if it looses connectivity after 20 minutes it reboots. I've seen the ObserverIP reboot it self some time after IP address expiration. Then since it is a fresh reboot it finally gets a new IP address. If your router has a short DHCP lease time then this will happen more frequently on your network. For a home network I recommend a DHCP lease time of 8 days. DHCP lease time depending on router brand/model may need to be entered in minutes or seconds. So 8 days is 11,520 minutes or 691,200 seconds. Check your DHCP server settings, some are only 1 day. Obviously the immediate solution into go the static route for now but remembering to take the precautions I listed above. How do I know the ObserverIP is not renewing the IP lease at the half nor at the 3/4?...Because I watched the DHCP server logs on the router. If I was more curious I could set up a network sniffer to see if the DHCP renewal request is being sent but perhaps formated inappropriately. If it was open-source code I might of felt more inclined to do so, to fix it myself.
« Last Edit: October 19, 2018, 11:16:57 AM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline galfert

  • Forecaster
  • *****
  • Posts: 872
Firmware 4.4.9 Released

- Still has DHCP bug. Read notes on the following prior post in this thread. I recommend using Static IP.
https://www.wxforum.net/index.php?topic=34948.msg359069#msg359069
- Fixes Rain Gauge Calibration only for those that changed the value from the default 1.0.
- Fixes typo of the word Radiation on the Calibration page (yippee....I reported that)

Firmware update recommended steps (Everything will be erased!!!):
- write down your calibration offsets
- make note of your time zone settings
- make note of your model number and units of measure
- write down your rain totals in the Live Data page
- make note of your network settings (I recommend setting static because of current bug)
- make sure you have your weather network credentials if you are using the ObserverIP to upload (I'm not as I just use Meteobridge)
- If using a Meteobridge (WeatherBridge) or Raspberry Pi or other device to read from the ObserverIP turn them off (to avoid bad data)
- Update firmware on ObserverIP
- Press Reset button when prompted by update tool
- Open browser connection to newly updated ObserverIP
Using your saved notes fill in the the following:
- Change network settings back to your static saved settings
- Set station settings model number
- Set station settings time zone
- Set station settings desired units of measure
- Set Calibration offsets (at least you need to do absolute and relative pressure)
- Update Live Data page rain totals (you can only enter and click save one at a time because of auto page refresh - or click Stop Refresh before entering)
- Lastly go to Weather Network page and enter in credentials to WU and AW networks if you are using those with ObserverIP
- Remember to turn back on your Meteobridge (Weatherbridge) or Raspberry Pi or other device if you use those. (this will ensure you don't upload bad data - before you are done entering in calibrations)
« Last Edit: October 23, 2018, 05:03:07 PM by galfert »
WS-2902A | ObserverIP | WeatherBridge (Meteobridge)
WU: KFLWINTE111  |  PWSweather: KFLWINTE111
CWOP: FW3708  |  AWEKAS: 14814
Tele-Pole flag pole is here (not installed yet)

Offline Bushman

  • Forecaster
  • *****
  • Posts: 7076
    • Eagle Bay Weather
For anything important on my networks, I use static IPs.

 

anything