ELV Mobile Alerts gateway MA 10000

64 views
Skip to first unread message

Stefanie Drucker

unread,
Jan 1, 2020, 5:30:33 PM1/1/20
to weewx-user
Hi,

I've bought a Mobile Alerts gateway and various sensors recently and want to use it with weewx.

This gateway is an European version of the LaCrosse GW-1000U. It looks exactly the same, but obviously is different (see https://github.com/sarnau/MMMMobileAlerts/blob/master/MobileAlertsELVvsLaCrosse.markdown).

Anyone has the same weather station and managed to set up weewx receiving data from it?

Any help or hints appreciated. ☺️

Stef


mwall

unread,
Jan 1, 2020, 7:00:56 PM1/1/20
to weewx-user
you can try the weewx-interceptor driver:


set the device_type=lacrosse-bridge

the lacross bridge has a rather complicated protocol.  try to configure as much as you can with the vendor's GAS program - at the very least you must tell the GW1000 to communicate with the computer that is running weewx (there is no passive sniffing mode for the lacross GW1000U).  and please read the comments about GW1000U in the interceptor.py file.  it is a bit technical, but you will probably have to tweak the serial number.

finally, do not confuse the lacross GW1000U with the fine offset GW1000.  froggit, ecowitt (and soon others?) sell the fine offset GW1000B and GW1000BU - 915MHz, the GW1000A - 868MHz, and the GW1000 - 433MHz.

Stefanie Drucker

unread,
Jan 2, 2020, 6:06:54 AM1/2/20
to weewx-user
Thanks for the quick reply!
I've already installed the interceptor and tried to receive data from my weather station through it, but so far it didn't work...
First, maybe it's not possible to connect the gateway to the weewx server as it works with the GW-1000U.
And second, the protocol is different.

I think it's not necessary to reroute all the traffic to go only to weewx any more instead of the Mobile Alerts cloud server. There is a REST API they provide that allows to request the latest measurement data.

And it also works with the Conrad Connect service, where you can connect the station and use the data. That's nice because you can build your own dashboards there and even connect with other IFTT hardware.
But it's not built to be a weather dashboard only, so I'm not satisfied with the possibilities there - and some services have to be paid monthly...

Stefanie Drucker

unread,
Jan 2, 2020, 11:27:20 AM1/2/20
to weewx-user
Update:
  • The Mobile Alerts REST API only supports some of their sensors - most of my temp/hum sensors are not supported by the API.
  • I think the easiest way to gain sensor data is to parse the measurements from a website that is provided by Mobile Alerts. There's no password protection, all you need are the IDs of your weather station ('PhoneID') and the sensors, or even better the unique URLs showing the last measurements for each sensor. For sorry these are HTML tables only, no XML format. But still should be no problem to parse the values.
So sniffing is not required, just HTML parsing.
I think then the interceptor is the wrong driver, right?

mwall

unread,
Jan 2, 2020, 11:58:51 AM1/2/20
to weewx-user


On Thursday, January 2, 2020 at 11:27:20 AM UTC-5, Stefanie Drucker wrote:
Update:
  • The Mobile Alerts REST API only supports some of their sensors - most of my temp/hum sensors are not supported by the API.
  • I think the easiest way to gain sensor data is to parse the measurements from a website that is provided by Mobile Alerts. There's no password protection, all you need are the IDs of your weather station ('PhoneID') and the sensors, or even better the unique URLs showing the last measurements for each sensor. For sorry these are HTML tables only, no XML format. But still should be no problem to parse the values.
So sniffing is not required, just HTML parsing.
I think then the interceptor is the wrong driver, right?

if you use tcpdump or some other tool to capture the tcp/ip traffic between your station and mobile alerts servers, then it would be possible to extend the weewx-interceptor driver to recognize that protocol.  or just create a standalone driver just for that protocol.

you could scrape and parse html from the mobile alerts web site, but that approach has many problems of its own.

it might be possible to write a driver that uses the mobile alerts API to get data from mobile alerts, but if mobile alerts does not support all of the sensors, then that does not seem like time well spent.

m
Reply all
Reply to author
Forward
0 new messages