meteohub.de

when you grant me remote login I can check what makes this differ from the Ecowitt. There must be something in the data...

It is not possible to get data to the Meteobridge with the HP2551 console.

The GW1000 and the HP2551 may seem similar but they aren't. Only the GW1000 has the required API to send data to the Meteobridge.

You can verify what I'm saying by simply running the WS View mobile app. In the WS View app you'll notice that you can only get live data from the GW1000 and not from the HP2551. This is by design. The WS View app gets live data from the GW1000 using the same API that the Meteobridge uses.

You will be able to use other methods to send data from the GW1000 and from the HP2551 that are supported by other applications. This is done by using the "Customzied" server upload feature of both devices. This is a totally different method of data interchange. This is a PUSH method from the console to the software of your choice.

The GW1000 API method is different in that it is a PULL method …where the Meteobridge asks for the data. PUSH and PULL is the difference between the "Customized" server upload method and the GW1000 API method. In one case you are sending it from the console and in the other case the software is the one asking for it.

TL;DR
Only the GW1000 is compatible with the Meteobridge because the data interchange method is different and only supported by the GW1000.

Some programs out there tunnel the GW1000 traffic going to WU through itself and read data by that. Meteobridge does not do this, but connects directly to the GW1000 to read data. In order to receive data from the GW1000 an initial "send data" request needs to be sent to the GW1000. It looks like this initial string is not recognized by the HP consoles and may be they don't offer any API to read data from at all.

Is there a PC program in the box that does directly read data from the console? If so, sniffing the TCP/IP traffic between the program and the console might shed some light into how to make the console talk.

The supported protocols are as follows...

HP2551
- [PUSH] Customized server upload in WU protocol to any desired IP (limited basic sensors that WU supports)
- [PUSH] Customized server upload in Ecowitt protocol to any desired IP (all sensors)

GW1000
- [PUSH] Customized server upload in WU protocol to any desired IP (limited basic sensors that WU supports)
- [PUSH] Customized server upload in Ecowitt protocol to any desired IP (all sensors)
- [PULL] GW1000 API of all sensor data (same method that WS View app uses to get live data from GW1000 only)

The GW1000 represents a minimal investment. If you want to reliably run the Meteobridge with a Fine Offset station then the GW1000 is indispensable. You can also get the Froggit DP1500 as it is a GW1000 by another name from Froggit as long as you have the 868 MHz station parts that Froggit uses.

There is no way to have the HP2551 support the GW1000 API protocol method....it just isn't baked into this console to support this method.

Essentially only the GW1000 supports the API PULL method of getting data...which is what the Meteobridge supports. Technically speaking there is one other device that also supports the GW1000 API method but it is very rare and not sold by very many resellers and that is the WH2650. However do not confuse the WH2650 with the older similar looking ObserverIP because they are not the same.

The Meteobridge does support the older ObserverIP which is a method of screen scraping the HTML page on that device. Which is a method that I'm not very fond of because the ObserverIP is underpowered to reliably provide data by continually generating this HTML page and having it read by the Meteobridge.

Thanks for offering remote login. I did with one user and as Georg lined out, the console does not respond to API requests. So I can't do anything here. sorry.

At the heart of the HP2551 and the GW1000 the same chipset is being used I believe. Therefore you are correct that if Fine Offset/Ecowitt wanted the HP2551 could be made to support the same API data method as the GW1000. But thus is not the case because there was originally no need for this from a product design standpoint. I'll explain...

The HP2551 is a console with a built in display. This display shows you live data from all acquired sensors. The GW1000 is also a console but without a physical display, thus a method to display live data needed to be designed into the product. The solution was the GW1000 API so that the WS View app could see the live data. The GW1000 needs a method to show live data because it has no screen. The HP2551 doesn't need to support this API because it has its own display.

Okay I know what you are going to say or ask next. So here is my answer.... The GW1000 API was not originally designed as a method for software applications to get data. It just was not part of the overall plan. If an application needs data then what was designed into the product was the "Customized" server upload [PUSH] feature using your choice of WU or Ecowitt protocols.

But realizing the potential that the GW1000 API method presents as a data acquisition method I set out to work with Fine Offset/Ecowitt to see about getting applications to support this API. At first there was not much interest from the company. It was only after I presented the opportunities and benefits of working with software developers such as Meteobridge that then they changed their mind. At first the decision was made to only allow this API to be used by Meteobridge. Thus Meteobridge enjoyed an initial exclusive in supporting this new GW1000 and its API method of data acquisition. Even still this method that has now be made available to a small group of developers (about 4 of them), the API remains not in the public domain because it is still being developed and the documentation is not final and these developers like Meteobridge need to work hard at supporting the API and its changes. At some point the API will go public...but there is no time line for this at this point. So don't ask for it...it just isn't available. Boris has it but it is under NDA. Frankly if you want to develop your own application you are better off using the PUSH methods as they are much easier to work with and you get all the same data. You have to understand that developing an API is something that needs to be done with attention to good planning. It is for this reason that an API that is realized into the open public too soon can hamper future development. Because an API in the wild means that people all over start then using it and then future changes need to be done with backwards compatibility and this can hamper future development. If the API is closed or limited then bigger changes can happen without repercussion. There have already been some major changes to the API that broke things ...but being a limited availability API everyone involved understands and everyone has to then quickly make changes. Easy to do when it is a limited availability API as it is now. This is how all good software and products are designed.

When you asked Lucy if the HP2551 could act as a Gateway like the GW1000 she answered correctly, and the answer is yes. But that was a vague question. The HP2551 and GW1000 both act as a gateway for all the same sensors and they both upload to all the same online services. And they both support the WU and Ecowitt customized server upload methods. You didn't ask if the HP2551 was compatible with Meteobridge...because then I know Lucy would have answered that it is not compatible, and that is a minor detail.

After all Fine Offset/Ecowitt I think could probably develop the HP2551 to also have the GW1000 API support but then they would lose out on all the sales of the GW1000. Why should they do that? It isn't like the GW1000 is that costly. If you need the GW1000 API then buy a GW1000. Just adding a feature to a product doesn't always make sense. The more features you add to a product the more complex that the instruction manual needs to be and the more support calls it will generate. Imagine the confusion of people that have a HP2551 and if it were to also produce live data over on the WS View app (because of the API) that then they may wonder where that data is coming from...is it from the console or from the Internet? Then there is the complexity of having to do more firmware development and testing for this added feature on this other device. Sure there could also be users that could embrace the complexity and added features set. There is no right and no wrong. You can suggest to the company that they make changes. After all Fine Offset/Ecowitt have shown that they very much listen to their customers. But I can tell you from working with them that they still hold final judgement. They will not tell you no. They are very polite and they will simply just tell you thank you and that they will consider it. That doesn't mean yes they will do it. It just means okay thank you for letting them know and goodbye. Then whatever happens, happens, and its up to them. Surely if enough people ask for something then there is higher probability. But I can tell you right now that the vast majority of users that want the expanded capabilities just buy both a GW1000 and a HP2551, and it doesn't break the budget.

Well my ideas are just my way of rationalizing why things are the way they are. It doesn't mean that I agree with my own ideas as being the way that things should be. I'm only offering conjecture into the manufacture's mind.

I'm not against the HP2551 having the API capability. The HP2551 came before the GW1000 existed. The HP2551 was not designed to have the API because it has its own screen. Then along comes the GW1000 as a way to have a more basic system and the need for the API becomes part of the requirements for the device. There likely was never a reflection back onto the HP2551 to adopt this new capability that was designed for the GW1000. I just see it as it is what it is.

Let us know what response you get after discussing further with Lucy.

Thank you for the follow up. Good to know what they responded.