Yes Method #1 is the easiest to implement but requires some more investment. If you are willing to get more technical then you can save some money. For example instead of buying a WeatherBridge you can make your own Meteobridge device and then just pay for the Meteobridge license. That saves a bit.
I would like to say though to have full disclosure that there are some benefits on paying more to get the WeatherBridge versus a DIY Meteobridge.
- WeatherBridge includes a valued $150 license to publish to ambientweather.net. But if you have a WS-2xxx console or ObserverIP then you already have this capability. The ability to upload with the Meteobridge to ambientweather.net is something that might appeal to Davis station owners using the Meteobridge so that they too can upload to ambientweather.net.
- If you bought a WeatherBridge then it has full warranty from Ambient for a year. If you make your own Meteobridge then you'll have to deal with T-Link and any issues that messing with the firmware may lave you without warranty. If you make a DIY Meteobridge then you pretty much need to support it yourself. Unless you need just software support from Meteobridge which your license will cover for 2 years (which you can renew for and additional 2 years at the cost of 19 Euro.)
- Obviously the WeatherBridge is ready to be used out of the box. Saves time and aggravation if technical skills changing device firmware may present a challenge to some.
So yes it may seem like a lot of extra software and hardware just to gain the ability to upload to CWOP. It could be something that ambientweather.net easily and simply provided like you mentioned. But CWOP is a different type of network than WU or PWSweather or WeatherCloud and many others. With CWOP neighbors matter. How they maintain their network is critical to your station ratings. With most other networks (WU, PWSweather, WeatherCloud.. etc) your neighbor with the crappy ancient LaCrosse or Oregon Scientific doesn't affect you.
Therefore I would argue that making CWOP too accessible to the novice or Joe Schmo may hurt the quality of data that NWS gets via the MADIS project. If having a CWOP station is just a simple checkbox to users, then many users may not take the time to learn about proper siting or hardware maintenance or even staying on top of bad sensors to replace them. So if the barriers to entry of CWOP mean added hardware and expense then it will only appeal to those that really want it and will know how to calibrate a barometer and maintain their stations properly.
When a certain irrigation controller brand that I won't mention by name (reason below) first came on the market they only supported data from WeatherCloud and CWOP (MADIS). On the this company's forums many users were upset that they couldn't utilize the multitude of WU stations for their controller. So a solution evolved on the company forum to have the controller owners (that didn't own any weather hardware) to run data screen scraping technology that then published it to PWSweather and/or CWOP as a new station for them to use. Here you have a situation where some of these irrigation controller owners taking other people's data on WU and just creating a new station on another network just so that they could have their controller gain the ability to have local weather data. Seems harmless at first. Till you consider that they have no control over the maintenance of that WU Station data they are repurposing over to a another important public weather network. It did not matter to these people if the data or hardware reporting on WU is less than perfect, whose data they were repurposing. They care not about barometer calibration. They only care about rainfall and maybe temperature to a lesser extent. So here is a situation where on CWOP fake stations are showing up that are not helping the network, and causing headaches for true CWOP station owners that are now being judged on ghost fake crappy stations with no maintenance. We don't want every WU Station to show up on CWOP. We only want good stations there. The person whose WU data was repurposed also has no idea that their data is being republished. This is a topic that I don't like to talk about too much and I don't ever mention the brand of irrigation controller because I don't want to enable Google searches to reveal this solution to other users of this irrigation controller. I'll give you a hint... R* A C=H#I +O just read the letters for the brand (entered that way to thwart searching). People please do not follow up with this brand name in this thread as you enable this solution to show up on Google searches. In a way I'm glad that the newest generation of that device now allows for WU stations to be used. But what a selfish solution they came up with before hu?
Getting back to understanding why the CWOP requires all these components. Ambient Weather sells hardware that only reports to common popular weather services. The new display consoles do not have USB connectivity nor network connectivity to read data from them. A software solution came about from Boris seller of Meteobridge software. Ambient embraced this software and hardware solution and made easily available to customers. Since it is not possible to talk to the console the solution for Meteobridge was to read the data from the ObserverIP. So it may seem complicated and requiring a lot of components but it was not master planned solution rather just something that came about. If you only cared about CWOP you could also save money by not getting a WS-2902A console. If you buy a WS-1550-IP then it comes with an ObserverIP and no console. Then just add the WeatherBridge and you are at $306 including shipping for a complete solution. And you can have the complete solution for much less (like barely more than $200) if you opted for the DIY Meteobridge instead.
