Topic: New to Meteobridge - getting an odd error and behavior

[kmahler]

I just flashed my MR-3020 last night with the meteobridge firmware. I configured it this morning and have yet to get it working. The process went about like this:

• Flashed MR-3020
• Configured Meteobridge for static IP and WU station id and other data
• Rebooted, had an error to set the timezone, set the timezone correctly, unit rebooted
• Meteobridge never worked again. Flashing quickly, can't connect
• Left it for hours, went and fixed girlfriend's stereo
• Tried doing reset, then factory reset, never did anything
• Kept rebooting it, it finally came up, I could log in and see everything, plugged in WS-2080, no live data
• Rebooted unit thinking that might get it talking to WS-2080
• Fast flashing again
• repeat several times, frustrated

I have it up again but no WX plugged in and I'm checking the config to see if I screwed anything up and I see this. The station ID is entered correctly. WTF is it talking about?
 [ You are not allowed to view attachments ]

So far, I'm not impressed with this little box everyone raves about. I'm not your average user. I work on computers for a living.

[Jáchym]

Hi,
I would check two things:
1. make sure there is no trailing space at the end of the WU ID
2. I know that for my template (Meteotemplate) Meteobridge sometimes also shows "error" despite the fact the actual update works. So I would check if it is just showing the error (even though there might not be any) or if it really sends no data

[kmahler]

Hi,
I would check two things:
1. make sure there is no trailing space at the end of the WU ID
2. I know that for my template (Meteotemplate) Meteobridge sometimes also shows "error" despite the fact the actual update works. So I would check if it is just showing the error (even though there might not be any) or if it really sends no data

Thanks, there was a trailing space. You would think the checkmark shouldn't show up if it's going to complain about it. I was writing software in Apple Basic 30 years ago that would remove leading and trailing space where they were not wanted. The meteobridge developers should consider this approach.

[Jáchym]

Hi,
yes you are correct, in my scripts I also try to use the "trim" command everytime (usually with a comment such as "lets trim spaces in case user feels like it would be fun to insert extra spaces") But I know this can also happen accidentally and is hard to spot.

I will email Boris about this (MB developer).

Glad the problem is solved.

[docbee]

Thanks for finding this bug inconvenience. Will be addressed in the next update.

If you are looking for bug free software, you better wait for paradise to come.

[Jáchym]

LOL

Once AI gets even smarter.... and it might not be that far away....

[kmahler]

Okay so the meteobridge has been up and running a couple of days. I noticed something odd today.  Look at 2:30am and 8:50pm. This station hasn't done anything like this in the over 6 years it's been in service. It didn't do it yesterday and the meteobridge was running then. I seriously doubt this is meteobridge related but thought I'd ask if anyone has see this before and found the gremlin.

 [ You are not allowed to view attachments ]

[Jáchym]

Hi,
it will be relatively difficult, if at all possible to find what was causing this. it could be a glitch in MB, problems with communication between MB and the station, problems at WU side. Just wait and see if this persists and if you can find any pattern in these spikes

[Bushman]

I see this occasionally with my Acurite station connected to MB, but never with my Davis VP connected to MB.

[Mattk]

I would be looking more at the source of the data, the sensors or the sensor/interface module before being sent to or read by MB

[kmahler]

I would be looking more at the source of the data, the sensors or the sensor/interface module before being sent to or read by MB

As I said in the original post, this station has been running without these glitches for over 6 years. It did it again this morning except instead of spiking up, it spiked down. Tomorrow night I'm going to move the station off of the meteobridge and put it back on Weathersnoop to see if the problem follows the station. If not, it must be something meteobridge related.

 [ You are not allowed to view attachments ]

[Bushman]

Did you recently update MB firmware?  If so, roll back to the previous, presumably working, prior version.

[kmahler]

Did you recently update MB firmware?  If so, roll back to the previous, presumably working, prior version.

This WS-2080 was running for over 6 years reporting to WU using Weathersnoop on a Mac computer. I recently (in the past week) moved it to a brand new Meteobridge. I have never run it on a meteobridge prior to now.

[Bushman]

Ahhh...  FWIW when I used Fine Offset stuff it threw all sorts of crap into the data stream that MB had a hard time separating the wheat from the chaff.  Boris did a lot of work to clean most of it up.  Maybe that is the same thing here?

[Jáchym]

My WH1080 does that too

[kmahler]

Okay, now I'm convinced the MB is the source of the problem. Early this morning it went though a period of not reporting. This has caused me to lose my Gold Star (kidding, I don't care but, I did lose it).

This morning the unit stopped reporting for a period around the same time the spike showed up yesterday. My two other stations, both using the same internet connection and house power showed no anomalies during this period of time.

WS-2080 on new Meteobridge
 [ You are not allowed to view attachments ]

WS-1400-IP reporting directly
 [ You are not allowed to view attachments ]

Davis VP2 reporting via Weather Display
 [ You are not allowed to view attachments ]

[Bushman]

The data you present does not support your conclusion.  Here's how to check:  connect the Davis to the MB and see if the drops happen.  If so then your hypothesis was correct.  Otherwise it is (likely) the crappy data stream  in the WH  station.

[kmahler]

The data you present does not support your conclusion.  Here's how to check:  connect the Davis to the MB and see if the drops happen.  If so then your hypothesis was correct.  Otherwise it is (likely) the crappy data stream  in the WH  station.

So over six years of no glitches doesn't support my conclusion? The only element changed in the equation is the removal of Weathersnoop and the addition of the MB. That's pretty strong support for my conclusion. Putting the Davis on the MB would be changing two elements, not nearly as strong of support for a conclusion. I have no history with the Davis as it is brand new to me. I think my findings are solid.

[docbee]

Does the messages section on system tab of Meteobridge not give any indication what happened?
How is the WS2080 connected? Do you use the mandatory USB 2.0 hub?

[kmahler]

Does the messages section on system tab of Meteobridge not give any indication what happened?
How is the WS2080 connected? Do you use the mandatory USB 2.0 hub?

I am using a USB 2.0 hub. The MB wouldn't talk to the WS-2080 without it.

Thanks for that idea. Here is what the logs say:

system (12.04.2017 00:27:23): stop of logging process initiated.
system (12.04.2017 00:27:29): start of logging process initiated.
logger (12.04.2017 00:27:30): historical data loaded (19 records).
logger (12.04.2017 00:27:30): data logger (version 5.0t, build 11070) started.
logger (12.04.2017 00:27:31): connect station 0 (WH-1080/3080 via USB HID).
logger (12.04.2017 00:27:31): sensors are now providing data.
logger (12.04.2017 00:27:31): services started.
system (12.04.2017 00:44:52): stop of logging process initiated.
system (12.04.2017 00:44:58): start of logging process initiated.
logger (12.04.2017 00:44:59): historical data loaded (19 records).
logger (12.04.2017 00:44:59): data logger (version 5.0t, build 11070) started.
logger (12.04.2017 00:45:00): connect station 0 (WH-1080/3080 via USB HID).
logger (12.04.2017 00:45:00): sensors are now providing data.
logger (12.04.2017 00:45:00): services started.
system (12.04.2017 00:52:26): stop of logging process initiated.
system (12.04.2017 00:52:32): start of logging process initiated.
logger (12.04.2017 00:52:32): historical data loaded (19 records).
logger (12.04.2017 00:52:32): data logger (version 5.0t, build 11070) started.
logger (12.04.2017 00:52:33): connect station 0 (WH-1080/3080 via USB HID).
logger (12.04.2017 00:52:33): waiting for sensors (wind0, rain0, th0, thb0) to provide data.
logger (12.04.2017 00:52:33): services paused.
logger (12.04.2017 00:52:47): sensors are now providing data.
logger (12.04.2017 00:52:47): services started.
logger (12.04.2017 03:05:18): Bad th0(0) sensor data, "temperature x10" (18452) out of range [-500:2000]

WU shows no updated between 00:40-00:51

It appears that MB is having some issues with the data. I'll have to check if Weathersnoop offers the same level of detail on logging. If so, I'll move the station back to Weathersnoop and monitor a 24 hour period.

[Bushman]

The data you present does not support your conclusion.  Here's how to check:  connect the Davis to the MB and see if the drops happen.  If so then your hypothesis was correct.  Otherwise it is (likely) the crappy data stream  in the WH  station.

So over six years of no glitches doesn't support my conclusion? The only element changed in the equation is the removal of Weathersnoop and the addition of the MB. That's pretty strong support for my conclusion. Putting the Davis on the MB would be changing two elements, not nearly as strong of support for a conclusion. I have no history with the Davis as it is brand new to me. I think my findings are solid.

Never took stats huh?  That WS runs with no "apparent" errors does not mean the MB is at fault. How do you know it is not smoothing over the errors?  Like I said, if you were to use the MB on Davis AND it exhibited similar dropouts then you could state the error follows the box, ergo MB is at fault. Null hypothesis proved.

Funny though how my MB boxes work fine with Davis yet my low end systems seem to have problems.  Go figure.