In version prior to 3.4, the setting of every 5 seconds for Weather Underground worked perfectly. With v3.4, even with every 5 seconds set, the MB is sending new data every 15 seconds. I have rebooted the MB but same results.
Is this a new WU requirement (ie minimum every 15 sec) and the settings selections were simply not updated to reflect the new higher minimum send rate or is this a bug?
david
WU send frequency issue
Moderator: Mattk
Re: WU send frequency issue
When there is no new data, no fresh upload to WU is done, because repeating the same old stuff is not making sense. When you have more active wind changes, frequency might step up again 
Re: WU send frequency issue
But what happens if your sensor information (all sensors combined) does not change for say 10 minutes (very stable weather)? Does that mean that for 10 minutes there is no upload to WU? They seem to sample and store what you send every 5 minutes. Will they use the data from the beginning of the 10 minute period?
Does MB behave in the same way for all uploads, such as to CWOP etc.?
Does MB behave in the same way for all uploads, such as to CWOP etc.?
Re: WU send frequency issue
My wind info IS changing more frequently than every 15 seconds! Also I have noticed a few times where the refresh occurred when there actually was NO change in the data. This appears to be an abritrary hard setting rather than a dynamic one. One of the best features of MB was that it did NOT try to be too smart! If MB wants to make this dynamic mode an option that would be fine, but as it stands, it is not a welcome change.
David
David
Re: WU send frequency issue
There are a few conditions to be met:
1) when data logging starts, weather network feeding is halted until all expected sensors showing data.
2) upload to weather networks is checked each time weather data come in from the station.
3) when unchanged data is retrieved for a specific sensor from the station and a timeout (usually 1 minute) is not reached, then the unchanged repetitive data is not further processed and upload to weather network is not triggered.
This is all meant to avoid sending redundant data and keeping system load low.
I hope this is now enough detail and you are not expecting me to explain a SW with more than 100k lines of code on flow chart level
1) when data logging starts, weather network feeding is halted until all expected sensors showing data.
2) upload to weather networks is checked each time weather data come in from the station.
3) when unchanged data is retrieved for a specific sensor from the station and a timeout (usually 1 minute) is not reached, then the unchanged repetitive data is not further processed and upload to weather network is not triggered.
This is all meant to avoid sending redundant data and keeping system load low.
I hope this is now enough detail and you are not expecting me to explain a SW with more than 100k lines of code on flow chart level
Re: WU send frequency issue
I appreciate the added details of the logic behind triggering an update to WU. FYI, I am a retired, enterprise solutions architect, so SW is second nature to me having architected, written, debugged, and supported programs running well in the million of lines of complex code over the years.
This does not really change my dislike for MB making decisions outside of settings. The documented changes to MB ver 3.4 added nothing to my situation and I prefer the operational logic of 3.3. I have now turned OFF the update on reboot as I don't want any more unexpected surprises and set MB to stick to ver 3.3
david
This does not really change my dislike for MB making decisions outside of settings. The documented changes to MB ver 3.4 added nothing to my situation and I prefer the operational logic of 3.3. I have now turned OFF the update on reboot as I don't want any more unexpected surprises and set MB to stick to ver 3.3
david
Re: WU send frequency issue
I am logging my values to a personal server every 15 seconds using an HTTP get "service". The lines contain both values from primary sensors (e.g. th0temp-act) as well as averages etc. I see lots of lines that have duplicates as far as primary sensors is concerned.
Does this mean that the "not sending if not changed" only applies to the built-in wunderground option, and perhaps other built-in services, but not to any manually configured HTTP requests?
Or does it mean that if the literal URL for a GET request is identical to the prior one it will not be sent (unlikely in general because most would contain time, and thus differ)?
If yes to the former, can you (Boris) please list all the built-ins that behave this way, vs. the ones that don't?
I have to say that the decision not to upload "redundant" data is questionable because does not receiving data (on the server side) mean that nothing has changed, or that a sample for a particular time is simply missing. I suppose which one of these two is the desired behavior would depend on the service in question. I have not found documentation, either way, for wunderground.com for example.
If this behavior only applies to "built-ins" one can get around it by not using those and crafting your own custom HTTP requests.
Does this mean that the "not sending if not changed" only applies to the built-in wunderground option, and perhaps other built-in services, but not to any manually configured HTTP requests?
Or does it mean that if the literal URL for a GET request is identical to the prior one it will not be sent (unlikely in general because most would contain time, and thus differ)?
If yes to the former, can you (Boris) please list all the built-ins that behave this way, vs. the ones that don't?
I have to say that the decision not to upload "redundant" data is questionable because does not receiving data (on the server side) mean that nothing has changed, or that a sample for a particular time is simply missing. I suppose which one of these two is the desired behavior would depend on the service in question. I have not found documentation, either way, for wunderground.com for example.
If this behavior only applies to "built-ins" one can get around it by not using those and crafting your own custom HTTP requests.
Re: WU send frequency issue
I don't think there is any change on this between versions 3.3 and 3.4. But as you have made your opinion, fine.
Weather network feed services are triggered by new data and then it is checked if determined interval period has passed to give a fresh upload a go. This makes much sense because a user who has a station that delivers new data every minute and wants to operate WU in rapid fire will otherwise send tons of bogus packets to WU.
When you define your own upload service as a HTTP upload for example, this is purely time scheduled. So when you upload every 5 secs it will do so (a variance of 1 sec or so might happen). Here you define your own stuff and Meteobridge just does what you tell it. How well your server etc is coping with that is in your responsibility. In the weather network situation it is not your own decision which load to put onto the total system. I hope this makes intent and reasons behind it even a bit more clear.
Weather network feed services are triggered by new data and then it is checked if determined interval period has passed to give a fresh upload a go. This makes much sense because a user who has a station that delivers new data every minute and wants to operate WU in rapid fire will otherwise send tons of bogus packets to WU.
When you define your own upload service as a HTTP upload for example, this is purely time scheduled. So when you upload every 5 secs it will do so (a variance of 1 sec or so might happen). Here you define your own stuff and Meteobridge just does what you tell it. How well your server etc is coping with that is in your responsibility. In the weather network situation it is not your own decision which load to put onto the total system. I hope this makes intent and reasons behind it even a bit more clear.