Re: [weewx-user] Re: PWS data format for Interceptor

[Ives]

Hello, everyone I realize this is a rather old entry, but I'd like to share 
my findings. I've had some success on connecting to the realtime API using 
the socketIO-client-nexus library
Apparently it's regarding an issue with the socketio protocol used by the 
AW server, since the original socketio-client only supports the 1.x protocol
I've written a code that manages to connect and subscribe to my WS-2902, 
although it issues a Warning error for some reason, looks like it has 
something to do with it trying to call a polling transport for a 2nd time,  
still it looks like it doesn't affect the program (although it does get me 
a bit nervous)...

I'll attach the test code I used along with some of the results I've been 
getting, I've only been using powershell for tests, so apologies for it 
looking so cluttered...
I hope it's useful for you guys, I know you suffered as much as me trying 
to get this to work.

Cheers.

El lunes, 20 de agosto de 2018, 15:19:05 (UTC-5), Pat escribió:
>
> I have not. I was hoping someone from AW would reply as well. You may be 
> better off with the node developer for the time being. AW is using 
> socket.io which seems very node friendly, and not so much Python. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
from socketIO_client_nexus import SocketIO


def on_connect(*args):
print("Connected Yes", args)
print("attempting subscription")
socketIO.emit("subscribe", {"apiKeys":[apikey]})

def on_message(*args):
print("Message", args[0].decode("utf-8"))

def on_subscribed(*args):
print("Subscribed", args)

def on_data(*args):
print("DATA!", args)


appkey = "YOUR APPKEY HERE"
apikey = "YOUR APIKEY HERE"
socketIO = SocketIO("https://api.ambientweather.net;,
443,
transports=['websocket'],
params={"api":1,
"applicationKey":appkey})

socketIO.on("connect", on_connect)
socketIO.on("message", on_message)
socketIO.on("subscribed", on_subscribed)
socketIO.on("data", on_data)
# print("Waiting for data")
socketIO.wait(seconds=300)

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

I have not. I was hoping someone from AW would reply as well. You may be 
better off with the node developer for the time being. AW is using 
socket.io which seems very node friendly, and not so much Python. 


On Monday, August 20, 2018 at 4:05:08 PM UTC-4, Douglas Krug wrote:
>
> @pat Have you gotten any further with this? Really disappointed to see 
> that no one from Ambient Weather has chimed in or even sent me an email to 
> say that they won't for [insert reasons here].
>
> On Thursday, August 16, 2018 at 12:54:50 PM UTC-4, Pat wrote:
>>
>> That's my thought is trying to find the right combination. The 
>> documentation isn't exactly complete, but looking at the "supported" node 
>> library they reference, it shows the URL they are using. But they explicitly 
>> define websockets there too 
>> 
>> . 
>>
>> There's a way to get socket.io to fallback onto websockets 
>>  where you can use wss, but 
>> I haven't figured that bit out yet with AW.
>>
>>
>>
>> On Thursday, August 16, 2018 at 11:47:49 AM UTC-4, Thomas Keffer wrote:
>>>
>>> I guess I was wrong!
>>>
>>> I find it hard to believe that the Python socket.io library is 
>>> incapable of handling such a simple case. The problem must be some 
>>> combination of getting the base host, api endpoint, and parameters right.
>>>
>>> -tk
>>>
>>> On Thu, Aug 16, 2018 at 8:34 AM Pat  wrote:
>>>
 I tried that too and couldn't get it to work. Forgot to mention that. 

 Trying it a couple of different ways again, I get the apiKey is missing:

 with SocketIO('
 https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
  
 443, LoggingNamespace, verify=False ) as socketIO:
 socketIO.on('connect', on_connect)

 /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
 InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
 certificate verification is strongly advised. See: https://
 urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
 InsecureRequestWarning)

 WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io 
 [engine.io waiting for connection] unexpected status code (401 {"error"
 :"apiKey-missing"})

 Or the 404 again

 SocketIO(
 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
 LoggingNamespace,
 verify=False,
 params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' 
 })


 /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
 InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
 certificate verification is strongly advised. See: https://
 urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
 InsecureRequestWarning)

 WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
 YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected 
 status code (404 {"name":"NotFound","message":"Page not found","code":
 404,"className":"not-found","errors":{}})

 Pat




 On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>
> I'm betting this is a ssl certificate problem. Try setting 
> verify=False.
>
> -tk
>
> On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:
>
>> I'm still thinking about this, and since I can't get the socket.io 
>> real time stream 
>>  
>> to work in Python, I thought about using a timer to poll the endpoint. 
>> However it looks like they only update the endpoint every 5 minutes. I'm 
>> thinking that's not really a good option since you probably want real 
>> time 
>> loop data, and not a 5 minute archive. 
>>
>> Since it seems to be working with node, and you're familiar with 
>> node, maybe that's your best bet right now to get the real time updates 
>> out 
>> of AW? 
>>
>>
>>
>> Since you're a customer of AW, you could also email them asking for 
>> Python help with the real time endpoint 
>>  
>> and see what they say. Their API docs 
>>  
>> say "The easiest way to use the API is to use a Socket.io helper 
>> library. 
>> They are available in most languages.", but when I use their endpoint 
>> with 
>> a Python helper library all I get is a 404. 
>>
>> Here's the code from sockerIO_client's sample code 
>> . Nothing fancy here yet, 
>> just trying to connect, and it doesn't. 
>>
>> After doing sudo pip install 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

@pat Have you gotten any further with this? Really disappointed to see that 
no one from Ambient Weather has chimed in or even sent me an email to say 
that they won't for [insert reasons here].

On Thursday, August 16, 2018 at 12:54:50 PM UTC-4, Pat wrote:
>
> That's my thought is trying to find the right combination. The 
> documentation isn't exactly complete, but looking at the "supported" node 
> library they reference, it shows the URL they are using. But they explicitly 
> define websockets there too 
> 
> . 
>
> There's a way to get socket.io to fallback onto websockets 
>  where you can use wss, but 
> I haven't figured that bit out yet with AW.
>
>
>
> On Thursday, August 16, 2018 at 11:47:49 AM UTC-4, Thomas Keffer wrote:
>>
>> I guess I was wrong!
>>
>> I find it hard to believe that the Python socket.io library is incapable 
>> of handling such a simple case. The problem must be some combination of 
>> getting the base host, api endpoint, and parameters right.
>>
>> -tk
>>
>> On Thu, Aug 16, 2018 at 8:34 AM Pat  wrote:
>>
>>> I tried that too and couldn't get it to work. Forgot to mention that. 
>>>
>>> Trying it a couple of different ways again, I get the apiKey is missing:
>>>
>>> with SocketIO('
>>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
>>>  
>>> 443, LoggingNamespace, verify=False ) as socketIO:
>>> socketIO.on('connect', on_connect)
>>>
>>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>>> certificate verification is strongly advised. See: https://
>>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>>> InsecureRequestWarning)
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io 
>>> [engine.io waiting for connection] unexpected status code (401 {"error":
>>> "apiKey-missing"})
>>>
>>> Or the 404 again
>>>
>>> SocketIO(
>>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
>>> LoggingNamespace,
>>> verify=False,
>>> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' 
>>> })
>>>
>>>
>>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>>> certificate verification is strongly advised. See: https://
>>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>>> InsecureRequestWarning)
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
>>> YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected 
>>> status code (404 {"name":"NotFound","message":"Page not found","code":
>>> 404,"className":"not-found","errors":{}})
>>>
>>> Pat
>>>
>>>
>>>
>>>
>>> On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:

 I'm betting this is a ssl certificate problem. Try setting verify=False.

 -tk

 On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:

> I'm still thinking about this, and since I can't get the socket.io 
> real time stream 
>  
> to work in Python, I thought about using a timer to poll the endpoint. 
> However it looks like they only update the endpoint every 5 minutes. I'm 
> thinking that's not really a good option since you probably want real 
> time 
> loop data, and not a 5 minute archive. 
>
> Since it seems to be working with node, and you're familiar with node, 
> maybe that's your best bet right now to get the real time updates out of 
> AW? 
>
>
>
> Since you're a customer of AW, you could also email them asking for 
> Python help with the real time endpoint 
>  
> and see what they say. Their API docs 
>  
> say "The easiest way to use the API is to use a Socket.io helper library. 
> They are available in most languages.", but when I use their endpoint 
> with 
> a Python helper library all I get is a 404. 
>
> Here's the code from sockerIO_client's sample code 
> . Nothing fancy here yet, 
> just trying to connect, and it doesn't. 
>
> After doing sudo pip install socketIO_client
>
> I ran this code
>
> import logging
> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
> logging.basicConfig()
>
>
> from socketIO_client import SocketIO, LoggingNamespace
>
>
> def on_connect():
> print('connect')
>
>
> with SocketIO('
> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
> ', 443, 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

That's my thought is trying to find the right combination. The 
documentation isn't exactly complete, but looking at the "supported" node 
library they reference, it shows the URL they are using. But they explicitly 
define websockets there too 

. 

There's a way to get socket.io to fallback onto websockets 
 where you can use wss, but I 
haven't figured that bit out yet with AW.



On Thursday, August 16, 2018 at 11:47:49 AM UTC-4, Thomas Keffer wrote:
>
> I guess I was wrong!
>
> I find it hard to believe that the Python socket.io library is incapable 
> of handling such a simple case. The problem must be some combination of 
> getting the base host, api endpoint, and parameters right.
>
> -tk
>
> On Thu, Aug 16, 2018 at 8:34 AM Pat > 
> wrote:
>
>> I tried that too and couldn't get it to work. Forgot to mention that. 
>>
>> Trying it a couple of different ways again, I get the apiKey is missing:
>>
>> with SocketIO('
>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
>>  
>> 443, LoggingNamespace, verify=False ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>> certificate verification is strongly advised. See: https://
>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>> InsecureRequestWarning)
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
>> engine.io waiting for connection] unexpected status code (401 {"error":
>> "apiKey-missing"})
>>
>> Or the 404 again
>>
>> SocketIO(
>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
>> LoggingNamespace,
>> verify=False,
>> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })
>>
>>
>> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
>> InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
>> certificate verification is strongly advised. See: https://
>> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
>> InsecureRequestWarning)
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
>> YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected 
>> status code (404 {"name":"NotFound","message":"Page not found","code":404
>> ,"className":"not-found","errors":{}})
>>
>> Pat
>>
>>
>>
>>
>> On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>>>
>>> I'm betting this is a ssl certificate problem. Try setting verify=False.
>>>
>>> -tk
>>>
>>> On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:
>>>
 I'm still thinking about this, and since I can't get the socket.io 
 real time stream 
  
 to work in Python, I thought about using a timer to poll the endpoint. 
 However it looks like they only update the endpoint every 5 minutes. I'm 
 thinking that's not really a good option since you probably want real time 
 loop data, and not a 5 minute archive. 

 Since it seems to be working with node, and you're familiar with node, 
 maybe that's your best bet right now to get the real time updates out of 
 AW? 



 Since you're a customer of AW, you could also email them asking for 
 Python help with the real time endpoint 
  
 and see what they say. Their API docs 
  
 say "The easiest way to use the API is to use a Socket.io helper library. 
 They are available in most languages.", but when I use their endpoint with 
 a Python helper library all I get is a 404. 

 Here's the code from sockerIO_client's sample code 
 . Nothing fancy here yet, 
 just trying to connect, and it doesn't. 

 After doing sudo pip install socketIO_client

 I ran this code

 import logging
 logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
 logging.basicConfig()


 from socketIO_client import SocketIO, LoggingNamespace


 def on_connect():
 print('connect')


 with SocketIO('
 https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
 ', 443, LoggingNamespace ) as socketIO:
 socketIO.on('connect', on_connect)


 which outputs:

 WARNING:socketIO-client:api.ambientweather.net:443//socket.io [
 engine.io waiting for connection] unexpected status code (404 
 {"name":"NotFound","message":"Page not 
 found","code":404,"className":"not-found","errors":{}})

 Adding your API Key to that HTTPS endpoint:

 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

I've sent this conversation to supp...@ambientweather.com to see if they 
could offer some guidance or get involved with the discussion here. They 
have a Facebook API group for questions and discussion, but I think they 
didn't expect it to be so unloved! Nobody had posted a single comment there 
in the last 30 days.

On Thursday, August 16, 2018 at 11:15:26 AM UTC-4, Pat wrote:
>
> I'm still thinking about this, and since I can't get the socket.io real 
> time stream 
>  
> to work in Python, I thought about using a timer to poll the endpoint. 
> However it looks like they only update the endpoint every 5 minutes. I'm 
> thinking that's not really a good option since you probably want real time 
> loop data, and not a 5 minute archive. 
>
> Since it seems to be working with node, and you're familiar with node, 
> maybe that's your best bet right now to get the real time updates out of 
> AW? 
>
>
>
> Since you're a customer of AW, you could also email them asking for Python 
> help with the real time endpoint 
>  
> and see what they say. Their API docs 
>  
> say "The easiest way to use the API is to use a Socket.io helper library. 
> They are available in most languages.", but when I use their endpoint with 
> a Python helper library all I get is a 404. 
>
> Here's the code from sockerIO_client's sample code 
> . Nothing fancy here yet, just 
> trying to connect, and it doesn't. 
>
> After doing sudo pip install socketIO_client
>
> I ran this code
>
> import logging
> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
> logging.basicConfig()
>
>
> from socketIO_client import SocketIO, LoggingNamespace
>
>
> def on_connect():
> print('connect')
>
>
> with SocketIO('
> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY'
> , 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
>
> which outputs:
>
> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
> waiting for connection] unexpected status code (404 
> {"name":"NotFound","message":"Page not 
> found","code":404,"className":"not-found","errors":{}})
>
> Adding your API Key to that HTTPS endpoint:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
> ', 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
> gave me:
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> But the API key isn't missing, it's in the string :)
>
>
>
> Or if I did something even different (again from the examples 
> )
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
> LoggingNamespace,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
> 'YOUR_APPLICATION_KEY' })
>
> I get
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
>
>
>
>
> However, if I go to an online socket.io test tool 
> , and enter in your real 
> time endpoint, it connects just fine. This is farther than Python is 
> letting me get. 
>
> [image: socketio.png]
> Again, not sure where to go from here. Maybe Node is your best bet. But 
> also maybe the information above is enough info to get help from them if 
> you do end up reaching out to them?
>
>
>
>
> On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>>
>> No, those are using sockets like how you and I think sockets are. I'm 
>> familiar with traditional sockets (my SocketLogger driver, and I forked the 
>> meteostick driver to use sockets) and I'm familiar with websockets, but 
>> this is using socket.io which is a websocket, but not a normal websocket 
>> apparently. It's designed to support old browsers so they use a bit of a 
>> custom algo to make it happen. 
>>
>> Since AW is using https and not wss, only the socketIO-client Python lib 
>> will work, but when trying to connect to the endpoint it gives a 404. But 
>> using the same endpoint on an online JavaScript socket.io test tool, its 
>> a success. Could be a limitation with the lib.
>>
>> The AW socket.io endpoint is for the real-time streaming data from 
>> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the 
>> driver and just request data every 10 seconds (or something) and submit to 
>> the loop. Downside could be duplicate timestamps, unless the weewx loop 
>> already allocates for that? 

Re: [weewx-user] Re: PWS data format for Interceptor

[Thomas Keffer]

I guess I was wrong!

I find it hard to believe that the Python socket.io library is incapable of
handling such a simple case. The problem must be some combination of
getting the base host, api endpoint, and parameters right.

-tk

On Thu, Aug 16, 2018 at 8:34 AM Pat  wrote:

> I tried that too and couldn't get it to work. Forgot to mention that.
>
> Trying it a couple of different ways again, I get the apiKey is missing:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
> 443, LoggingNamespace, verify=False ) as socketIO:
> socketIO.on('connect', on_connect)
>
> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See: https://
> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
> InsecureRequestWarning)
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> Or the 404 again
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443,
> LoggingNamespace,
> verify=False,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })
>
>
> /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See: https://
> urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
> InsecureRequestWarning)
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDR/socket.io [engine.io waiting for connection] unexpected
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
> Pat
>
>
>
>
> On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>>
>> I'm betting this is a ssl certificate problem. Try setting verify=False.
>>
>> -tk
>>
>> On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:
>>
>>> I'm still thinking about this, and since I can't get the socket.io real
>>> time stream
>>> 
>>> to work in Python, I thought about using a timer to poll the endpoint.
>>> However it looks like they only update the endpoint every 5 minutes. I'm
>>> thinking that's not really a good option since you probably want real time
>>> loop data, and not a 5 minute archive.
>>>
>>> Since it seems to be working with node, and you're familiar with node,
>>> maybe that's your best bet right now to get the real time updates out of
>>> AW?
>>>
>>>
>>>
>>> Since you're a customer of AW, you could also email them asking for
>>> Python help with the real time endpoint
>>> 
>>> and see what they say. Their API docs
>>> 
>>> say "The easiest way to use the API is to use a Socket.io helper library.
>>> They are available in most languages.", but when I use their endpoint with
>>> a Python helper library all I get is a 404.
>>>
>>> Here's the code from sockerIO_client's sample code
>>> . Nothing fancy here yet,
>>> just trying to connect, and it doesn't.
>>>
>>> After doing sudo pip install socketIO_client
>>>
>>> I ran this code
>>>
>>> import logging
>>> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
>>> logging.basicConfig()
>>>
>>>
>>> from socketIO_client import SocketIO, LoggingNamespace
>>>
>>>
>>> def on_connect():
>>> print('connect')
>>>
>>>
>>> with SocketIO('
>>> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
>>> ', 443, LoggingNamespace ) as socketIO:
>>> socketIO.on('connect', on_connect)
>>>
>>>
>>> which outputs:
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io
>>> waiting for connection] unexpected status code (404
>>> {"name":"NotFound","message":"Page not
>>> found","code":404,"className":"not-found","errors":{}})
>>>
>>> Adding your API Key to that HTTPS endpoint:
>>>
>>> with SocketIO('
>>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
>>> ', 443, LoggingNamespace ) as socketIO:
>>> socketIO.on('connect', on_connect)
>>>
>>> gave me:
>>>
>>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io
>>> [engine.io waiting for connection] unexpected status code (401 {"error":
>>> "apiKey-missing"})
>>>
>>> But the API key isn't missing, it's in the string :)
>>>
>>>
>>>
>>> Or if I did something even different (again from the examples
>>> )
>>>
>>> SocketIO(
>>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443,
>>> LoggingNamespace,
>>> params={'apiKey': 'YOUR_API_KEY', 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

I tried that too and couldn't get it to work. Forgot to mention that. 

Trying it a couple of different ways again, I get the apiKey is missing:

with 
SocketIO('https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APP_KEY=YOUR_API_KEY',
 
443, LoggingNamespace, verify=False ) as socketIO:
socketIO.on('connect', on_connect)

/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
InsecureRequestWarning)

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
engine.io waiting for connection] unexpected status code (401 {"error":
"apiKey-missing"})

Or the 404 again

SocketIO(
'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDR', 443, 
LoggingNamespace,
verify=False,
params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 'YOUR_APP_KEY' })


/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:857: 
InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings 
InsecureRequestWarning)

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/YOUR_MAC_ADDR/
socket.io [engine.io waiting for connection] unexpected status code (404 {
"name":"NotFound","message":"Page not found","code":404,"className":
"not-found","errors":{}})

Pat




On Thursday, August 16, 2018 at 11:24:00 AM UTC-4, Thomas Keffer wrote:
>
> I'm betting this is a ssl certificate problem. Try setting verify=False.
>
> -tk
>
> On Thu, Aug 16, 2018 at 8:15 AM Pat > 
> wrote:
>
>> I'm still thinking about this, and since I can't get the socket.io real 
>> time stream 
>>  
>> to work in Python, I thought about using a timer to poll the endpoint. 
>> However it looks like they only update the endpoint every 5 minutes. I'm 
>> thinking that's not really a good option since you probably want real time 
>> loop data, and not a 5 minute archive. 
>>
>> Since it seems to be working with node, and you're familiar with node, 
>> maybe that's your best bet right now to get the real time updates out of 
>> AW? 
>>
>>
>>
>> Since you're a customer of AW, you could also email them asking for 
>> Python help with the real time endpoint 
>>  
>> and see what they say. Their API docs 
>>  
>> say "The easiest way to use the API is to use a Socket.io helper library. 
>> They are available in most languages.", but when I use their endpoint with 
>> a Python helper library all I get is a 404. 
>>
>> Here's the code from sockerIO_client's sample code 
>> . Nothing fancy here yet, 
>> just trying to connect, and it doesn't. 
>>
>> After doing sudo pip install socketIO_client
>>
>> I ran this code
>>
>> import logging
>> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
>> logging.basicConfig()
>>
>>
>> from socketIO_client import SocketIO, LoggingNamespace
>>
>>
>> def on_connect():
>> print('connect')
>>
>>
>> with SocketIO('
>> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY
>> ', 443, LoggingNamespace ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>>
>> which outputs:
>>
>> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
>> waiting for connection] unexpected status code (404 
>> {"name":"NotFound","message":"Page not 
>> found","code":404,"className":"not-found","errors":{}})
>>
>> Adding your API Key to that HTTPS endpoint:
>>
>> with SocketIO('
>> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
>> ', 443, LoggingNamespace ) as socketIO:
>> socketIO.on('connect', on_connect)
>>
>> gave me:
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
>> engine.io waiting for connection] unexpected status code (401 {"error":
>> "apiKey-missing"})
>>
>> But the API key isn't missing, it's in the string :)
>>
>>
>>
>> Or if I did something even different (again from the examples 
>> )
>>
>> SocketIO(
>> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
>> LoggingNamespace,
>> params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
>> 'YOUR_APPLICATION_KEY' })
>>
>> I get
>>
>> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
>> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
>> status code (404 {"name":"NotFound","message":"Page not found","code":404
>> ,"className":"not-found","errors":{}})
>>
>>
>>
>>
>>
>> However, if I go to an online socket.io test tool 
>> 

Re: [weewx-user] Re: PWS data format for Interceptor

[Thomas Keffer]

I'm betting this is a ssl certificate problem. Try setting verify=False.

-tk

On Thu, Aug 16, 2018 at 8:15 AM Pat  wrote:

> I'm still thinking about this, and since I can't get the socket.io real
> time stream
> 
> to work in Python, I thought about using a timer to poll the endpoint.
> However it looks like they only update the endpoint every 5 minutes. I'm
> thinking that's not really a good option since you probably want real time
> loop data, and not a 5 minute archive.
>
> Since it seems to be working with node, and you're familiar with node,
> maybe that's your best bet right now to get the real time updates out of
> AW?
>
>
>
> Since you're a customer of AW, you could also email them asking for Python
> help with the real time endpoint
> 
> and see what they say. Their API docs
> 
> say "The easiest way to use the API is to use a Socket.io helper library.
> They are available in most languages.", but when I use their endpoint with
> a Python helper library all I get is a 404.
>
> Here's the code from sockerIO_client's sample code
> . Nothing fancy here yet, just
> trying to connect, and it doesn't.
>
> After doing sudo pip install socketIO_client
>
> I ran this code
>
> import logging
> logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
> logging.basicConfig()
>
>
> from socketIO_client import SocketIO, LoggingNamespace
>
>
> def on_connect():
> print('connect')
>
>
> with SocketIO('
> https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY'
> , 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
>
> which outputs:
>
> WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io
> waiting for connection] unexpected status code (404
> {"name":"NotFound","message":"Page not
> found","code":404,"className":"not-found","errors":{}})
>
> Adding your API Key to that HTTPS endpoint:
>
> with SocketIO('
> https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY
> ', 443, LoggingNamespace ) as socketIO:
> socketIO.on('connect', on_connect)
>
> gave me:
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
> engine.io waiting for connection] unexpected status code (401 {"error":
> "apiKey-missing"})
>
> But the API key isn't missing, it's in the string :)
>
>
>
> Or if I did something even different (again from the examples
> )
>
> SocketIO(
> 'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443,
> LoggingNamespace,
> params={'apiKey': 'YOUR_API_KEY', 'applicationKey':
> 'YOUR_APPLICATION_KEY' })
>
> I get
>
> WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
> YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected
> status code (404 {"name":"NotFound","message":"Page not found","code":404,
> "className":"not-found","errors":{}})
>
>
>
>
>
> However, if I go to an online socket.io test tool
> , and enter in your real
> time endpoint, it connects just fine. This is farther than Python is
> letting me get.
>
> [image: socketio.png]
> Again, not sure where to go from here. Maybe Node is your best bet. But
> also maybe the information above is enough info to get help from them if
> you do end up reaching out to them?
>
>
>
>
> On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>>
>> No, those are using sockets like how you and I think sockets are. I'm
>> familiar with traditional sockets (my SocketLogger driver, and I forked the
>> meteostick driver to use sockets) and I'm familiar with websockets, but
>> this is using socket.io which is a websocket, but not a normal websocket
>> apparently. It's designed to support old browsers so they use a bit of a
>> custom algo to make it happen.
>>
>> Since AW is using https and not wss, only the socketIO-client Python lib
>> will work, but when trying to connect to the endpoint it gives a 404. But
>> using the same endpoint on an online JavaScript socket.io test tool, its
>> a success. Could be a limitation with the lib.
>>
>> The AW socket.io endpoint is for the real-time streaming data from
>> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the
>> driver and just request data every 10 seconds (or something) and submit to
>> the loop. Downside could be duplicate timestamps, unless the weewx loop
>> already allocates for that? Which could be a non-issue.
>>
>>
>> On Tuesday, August 14, 2018 at 11:39:10 PM UTC-4, gjr80 wrote:
>>>
>>> So nothing in the vantage or ws1 drivers or restx.py to help?
>>>
>>> Gary
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

I'm still thinking about this, and since I can't get the socket.io real 
time stream 
 to 
work in Python, I thought about using a timer to poll the endpoint. However 
it looks like they only update the endpoint every 5 minutes. I'm thinking 
that's not really a good option since you probably want real time loop 
data, and not a 5 minute archive. 

Since it seems to be working with node, and you're familiar with node, 
maybe that's your best bet right now to get the real time updates out of 
AW? 



Since you're a customer of AW, you could also email them asking for Python 
help with the real time endpoint 
 and 
see what they say. Their API docs 
 say 
"The easiest way to use the API is to use a Socket.io helper library. They 
are available in most languages.", but when I use their endpoint with a 
Python helper library all I get is a 404. 

Here's the code from sockerIO_client's sample code 
. Nothing fancy here yet, just 
trying to connect, and it doesn't. 

After doing sudo pip install socketIO_client

I ran this code

import logging
logging.getLogger('socketIO-client').setLevel(logging.DEBUG)
logging.basicConfig()


from socketIO_client import SocketIO, LoggingNamespace


def on_connect():
print('connect')


with SocketIO(
'https://api.ambientweather.net/?api=1=YOUR_APPLICATION_KEY', 
443, LoggingNamespace ) as socketIO:
socketIO.on('connect', on_connect)


which outputs:

WARNING:socketIO-client:api.ambientweather.net:443//socket.io [engine.io 
waiting for connection] unexpected status code (404 
{"name":"NotFound","message":"Page not 
found","code":404,"className":"not-found","errors":{}})

Adding your API Key to that HTTPS endpoint:

with SocketIO(
'https://api.ambientweather.net/v1/devices?applicationKey=YOUR_APPLICATION_KEY=YOUR_API_KEY'
, 443, LoggingNamespace ) as socketIO:
socketIO.on('connect', on_connect)

gave me:

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/socket.io [
engine.io waiting for connection] unexpected status code (401 {"error":
"apiKey-missing"})

But the API key isn't missing, it's in the string :)



Or if I did something even different (again from the examples 
)

SocketIO(
'https://api.ambientweather.net/v1/devices/YOUR_MAC_ADDRESS', 443, 
LoggingNamespace,
params={'apiKey': 'YOUR_API_KEY', 'applicationKey': 
'YOUR_APPLICATION_KEY' })

I get

WARNING:socketIO-client:api.ambientweather.net:443/v1/devices/
YOUR_MAC_ADDRESS/socket.io [engine.io waiting for connection] unexpected 
status code (404 {"name":"NotFound","message":"Page not found","code":404,
"className":"not-found","errors":{}})





However, if I go to an online socket.io test tool 
, and enter in your real 
time endpoint, it connects just fine. This is farther than Python is 
letting me get. 

[image: socketio.png] 
Again, not sure where to go from here. Maybe Node is your best bet. But 
also maybe the information above is enough info to get help from them if 
you do end up reaching out to them?




On Wednesday, August 15, 2018 at 9:04:34 AM UTC-4, Pat wrote:
>
> No, those are using sockets like how you and I think sockets are. I'm 
> familiar with traditional sockets (my SocketLogger driver, and I forked the 
> meteostick driver to use sockets) and I'm familiar with websockets, but 
> this is using socket.io which is a websocket, but not a normal websocket 
> apparently. It's designed to support old browsers so they use a bit of a 
> custom algo to make it happen. 
>
> Since AW is using https and not wss, only the socketIO-client Python lib 
> will work, but when trying to connect to the endpoint it gives a 404. But 
> using the same endpoint on an online JavaScript socket.io test tool, its 
> a success. Could be a limitation with the lib.
>
> The AW socket.io endpoint is for the real-time streaming data from 
> AmbientWeather. Perhaps plan B is to implement a time.sleep() in the 
> driver and just request data every 10 seconds (or something) and submit to 
> the loop. Downside could be duplicate timestamps, unless the weewx loop 
> already allocates for that? Which could be a non-issue. 
>
>
> On Tuesday, August 14, 2018 at 11:39:10 PM UTC-4, gjr80 wrote:
>>
>> So nothing in the vantage or ws1 drivers or restx.py to help?
>>
>> Gary
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

No, those are using sockets like how you and I think sockets are. I'm 
familiar with traditional sockets (my SocketLogger driver, and I forked the 
meteostick driver to use sockets) and I'm familiar with websockets, but 
this is using socket.io which is a websocket, but not a normal websocket 
apparently. It's designed to support old browsers so they use a bit of a 
custom algo to make it happen. 

Since AW is using https and not wss, only the socketIO-client Python lib 
will work, but when trying to connect to the endpoint it gives a 404. But 
using the same endpoint on an online JavaScript socket.io test tool, its a 
success. Could be a limitation with the lib.

The AW socket.io endpoint is for the real-time streaming data from 
AmbientWeather. Perhaps plan B is to implement a time.sleep() in the driver 
and just request data every 10 seconds (or something) and submit to the 
loop. Downside could be duplicate timestamps, unless the weewx loop already 
allocates for that? Which could be a non-issue. 


On Tuesday, August 14, 2018 at 11:39:10 PM UTC-4, gjr80 wrote:
>
> So nothing in the vantage or ws1 drivers or restx.py to help?
>
> Gary
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: PWS data format for Interceptor

[gjr80]

So nothing in the vantage or ws1 drivers or restx.py to help?

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

Proving to be a bit of a challenge. Does anyone have any socket.io Python 
experience? I'm following the dev guides but the endpoint keeps coming up 
as 404. If I try it with an online socket.io test tool, it works fine 
(using javascript). Hmm...

On Tuesday, August 14, 2018 at 11:55:50 AM UTC-4, Douglas Krug wrote:
>
> That sounds amazing. I haven’t requested the key yet, but will now and 
> send to you.
>
> On Tue, Aug 14, 2018 at 11:49 AM Pat > 
> wrote:
>
>> It should be doable. Just need to get Python connected to their websocket 
>> realtime endpoint and the rest of it (weewx driver wise) should be similar 
>> to the drivers I've written in the past. 
>>
>> I haven't played with Python websockets yet, but sounds fun to tinker 
>> with and figure out!
>>
>> If you're comfortable I may need your Ambient Weather API and APP keys 
>> (sent as a private message so its not public) to be able to read the data 
>> as a way to validate the driver. You should be able to change these when 
>> done to re-secure your keys. 
>>
>> On Tuesday, August 14, 2018 at 10:06:09 AM UTC-4, Douglas Krug wrote:
>>>
>>> *I no longer am using my Ambient ObserverIP, so I don't have test data 
>>> to use.* 
>>>
>>> I do of course, so let me know if I could help in this regard.
>>>
>>> On Tuesday, August 14, 2018 at 9:44:33 AM UTC-4, Douglas Krug wrote:

 *So maybe the thought here is to have your station submit to 
 AmbientWeather natively, and create a driver which gets the data from 
 Ambient's real-time subscribe system and submits it to weewx for archival?*

 Yes, that's the idea exactly! Ambient doesn't let you upload to their 
 server unless you buy a $150 license from them. But if you own their 
 equipment, there's no charge to upload. Since there's a way to subscribe 
 to 
 Ambientweather.net via their API, there's for sure a possibility to bring 
 it into Weewx. In fact, there doesn't even need to be node servers and 
 routers passing the data, but I don't know how to code, so I wouldn't be 
 able to execute the concept. The ambient2pwsweather server is needed if 
 you're not running Weewx, but if you are, it's redundant since you can 
 just 
 post to PWSweather from Weewx. It's the ambientweather.net piece that 
 is tricky due to their restrictions. However, everyone with any internet 
 connected Ambient Weather device and up-to-date firmware can upload to 
 ambientweather.net for free. So if there was just a way to subscribe 
 to data from ambientweather.net and bring it into Weewx, there would 
 be no need for Ambient Weather IP sniffing or listening, just an internet 
 connection, Weewx and a plugin.

 But I'm a home automation geek. I already have an always on Node.js 
 server running. I was reluctant to add another router, but I have several 
 of them and it was the easiest way to get data into Weewx. So adding 
 another piece to the puzzle doesn't phase me that much. It *can* all 
 be so simple, but it takes talented developers to do the work.

 On Tue, Aug 14, 2018 at 9:14 AM Pat  wrote:

>>> Taking a look at the ambient2pwsweather project, it looks like he's 
> really using the ambient-weather-api 
>  project as his heavy 
> lifting for ambient. And looking at the project it looks like what we 
> talked about where AmbientWeather's API documentation 
>  talks about how to 
> subscribe to data, but not how to submit data. 
>
> So maybe the thought here is to have your station submit to 
> AmbientWeather natively, and create a driver which gets the data from 
> Ambient's real-time subscribe system and submits it to weewx for 
> archival? 
>
> I've also upgraded to a Davis Vantage Pro 2, so I no longer am using 
> my Ambient ObserverIP, so I don't have test data to use. 
>
>
> On Tuesday, August 14, 2018 at 8:57:42 AM UTC-4, Pat wrote:
>>
>> The API into weewx would be a driver. Typically the weather equipment 
>> is directly connected and the driver would control the weather station. 
>> That's why I wrote the socket driver a few years ago because my 
>> equipment 
>> isn't directly connected. 
>>
>> The good news is the interceptor driver has multiple ways to input 
>> data into weewx, so it's probably as much of an API as you're going to 
>> find. By sending HTTP data to the driver's web server, it can then pass 
>> it 
>> to weewx like a standard driver would.
>>
>> That being said, I can't help but to think about others who may want 
>> to publish data to Ambient as well. As mentioned on wxforum, the Ambient 
>> documentation is kind of lacking for a developer and what the value 
>> names 
>> are to submit (and how... GET vs. POST). But if there's a project 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

That sounds amazing. I haven’t requested the key yet, but will now and send
to you.

On Tue, Aug 14, 2018 at 11:49 AM Pat  wrote:

> It should be doable. Just need to get Python connected to their websocket
> realtime endpoint and the rest of it (weewx driver wise) should be similar
> to the drivers I've written in the past.
>
> I haven't played with Python websockets yet, but sounds fun to tinker with
> and figure out!
>
> If you're comfortable I may need your Ambient Weather API and APP keys
> (sent as a private message so its not public) to be able to read the data
> as a way to validate the driver. You should be able to change these when
> done to re-secure your keys.
>
> On Tuesday, August 14, 2018 at 10:06:09 AM UTC-4, Douglas Krug wrote:
>>
>> *I no longer am using my Ambient ObserverIP, so I don't have test data to
>> use.*
>>
>> I do of course, so let me know if I could help in this regard.
>>
>> On Tuesday, August 14, 2018 at 9:44:33 AM UTC-4, Douglas Krug wrote:
>>>
>>> *So maybe the thought here is to have your station submit to
>>> AmbientWeather natively, and create a driver which gets the data from
>>> Ambient's real-time subscribe system and submits it to weewx for archival?*
>>>
>>> Yes, that's the idea exactly! Ambient doesn't let you upload to their
>>> server unless you buy a $150 license from them. But if you own their
>>> equipment, there's no charge to upload. Since there's a way to subscribe to
>>> Ambientweather.net via their API, there's for sure a possibility to bring
>>> it into Weewx. In fact, there doesn't even need to be node servers and
>>> routers passing the data, but I don't know how to code, so I wouldn't be
>>> able to execute the concept. The ambient2pwsweather server is needed if
>>> you're not running Weewx, but if you are, it's redundant since you can just
>>> post to PWSweather from Weewx. It's the ambientweather.net piece that
>>> is tricky due to their restrictions. However, everyone with any internet
>>> connected Ambient Weather device and up-to-date firmware can upload to
>>> ambientweather.net for free. So if there was just a way to subscribe to
>>> data from ambientweather.net and bring it into Weewx, there would be no
>>> need for Ambient Weather IP sniffing or listening, just an internet
>>> connection, Weewx and a plugin.
>>>
>>> But I'm a home automation geek. I already have an always on Node.js
>>> server running. I was reluctant to add another router, but I have several
>>> of them and it was the easiest way to get data into Weewx. So adding
>>> another piece to the puzzle doesn't phase me that much. It *can* all be
>>> so simple, but it takes talented developers to do the work.
>>>
>>> On Tue, Aug 14, 2018 at 9:14 AM Pat  wrote:
>>>
>> Taking a look at the ambient2pwsweather project, it looks like he's
 really using the ambient-weather-api
  project as his heavy
 lifting for ambient. And looking at the project it looks like what we
 talked about where AmbientWeather's API documentation
  talks about how to subscribe
 to data, but not how to submit data.

 So maybe the thought here is to have your station submit to
 AmbientWeather natively, and create a driver which gets the data from
 Ambient's real-time subscribe system and submits it to weewx for archival?

 I've also upgraded to a Davis Vantage Pro 2, so I no longer am using my
 Ambient ObserverIP, so I don't have test data to use.


 On Tuesday, August 14, 2018 at 8:57:42 AM UTC-4, Pat wrote:
>
> The API into weewx would be a driver. Typically the weather equipment
> is directly connected and the driver would control the weather station.
> That's why I wrote the socket driver a few years ago because my equipment
> isn't directly connected.
>
> The good news is the interceptor driver has multiple ways to input
> data into weewx, so it's probably as much of an API as you're going to
> find. By sending HTTP data to the driver's web server, it can then pass it
> to weewx like a standard driver would.
>
> That being said, I can't help but to think about others who may want
> to publish data to Ambient as well. As mentioned on wxforum, the Ambient
> documentation is kind of lacking for a developer and what the value names
> are to submit (and how... GET vs. POST). But if there's a project that's
> successfully posting data to Ambient, then maybe a weewx extension could 
> be
> created to post to Ambient. An extension like the one for wunderground or
> PWSWeather might be easy enough to fork for Ambient. This would save the
> need of setting up and maintaining a node server (and help those here who
> don't know what node is). The more complicated things get, the more
> potential for something to break and you not catching it (like your node
> server crashing and 

Re: [weewx-user] Re: PWS data format for Interceptor

[Pat]

It should be doable. Just need to get Python connected to their websocket 
realtime endpoint and the rest of it (weewx driver wise) should be similar 
to the drivers I've written in the past. 

I haven't played with Python websockets yet, but sounds fun to tinker with 
and figure out!

If you're comfortable I may need your Ambient Weather API and APP keys 
(sent as a private message so its not public) to be able to read the data 
as a way to validate the driver. You should be able to change these when 
done to re-secure your keys. 

On Tuesday, August 14, 2018 at 10:06:09 AM UTC-4, Douglas Krug wrote:
>
> *I no longer am using my Ambient ObserverIP, so I don't have test data to 
> use.* 
>
> I do of course, so let me know if I could help in this regard.
>
> On Tuesday, August 14, 2018 at 9:44:33 AM UTC-4, Douglas Krug wrote:
>>
>> *So maybe the thought here is to have your station submit to 
>> AmbientWeather natively, and create a driver which gets the data from 
>> Ambient's real-time subscribe system and submits it to weewx for archival?*
>>
>> Yes, that's the idea exactly! Ambient doesn't let you upload to their 
>> server unless you buy a $150 license from them. But if you own their 
>> equipment, there's no charge to upload. Since there's a way to subscribe to 
>> Ambientweather.net via their API, there's for sure a possibility to bring 
>> it into Weewx. In fact, there doesn't even need to be node servers and 
>> routers passing the data, but I don't know how to code, so I wouldn't be 
>> able to execute the concept. The ambient2pwsweather server is needed if 
>> you're not running Weewx, but if you are, it's redundant since you can just 
>> post to PWSweather from Weewx. It's the ambientweather.net piece that is 
>> tricky due to their restrictions. However, everyone with any internet 
>> connected Ambient Weather device and up-to-date firmware can upload to 
>> ambientweather.net for free. So if there was just a way to subscribe to 
>> data from ambientweather.net and bring it into Weewx, there would be no 
>> need for Ambient Weather IP sniffing or listening, just an internet 
>> connection, Weewx and a plugin.
>>
>> But I'm a home automation geek. I already have an always on Node.js 
>> server running. I was reluctant to add another router, but I have several 
>> of them and it was the easiest way to get data into Weewx. So adding 
>> another piece to the puzzle doesn't phase me that much. It *can* all be 
>> so simple, but it takes talented developers to do the work.
>>
>> On Tue, Aug 14, 2018 at 9:14 AM Pat > 
>> wrote:
>>
>>> Taking a look at the ambient2pwsweather project, it looks like he's 
>>> really using the ambient-weather-api 
>>>  project as his heavy 
>>> lifting for ambient. And looking at the project it looks like what we 
>>> talked about where AmbientWeather's API documentation 
>>>  talks about how to subscribe 
>>> to data, but not how to submit data. 
>>>
>>> So maybe the thought here is to have your station submit to 
>>> AmbientWeather natively, and create a driver which gets the data from 
>>> Ambient's real-time subscribe system and submits it to weewx for archival? 
>>>
>>> I've also upgraded to a Davis Vantage Pro 2, so I no longer am using my 
>>> Ambient ObserverIP, so I don't have test data to use. 
>>>
>>>
>>> On Tuesday, August 14, 2018 at 8:57:42 AM UTC-4, Pat wrote:

 The API into weewx would be a driver. Typically the weather equipment 
 is directly connected and the driver would control the weather station. 
 That's why I wrote the socket driver a few years ago because my equipment 
 isn't directly connected. 

 The good news is the interceptor driver has multiple ways to input data 
 into weewx, so it's probably as much of an API as you're going to find. By 
 sending HTTP data to the driver's web server, it can then pass it to weewx 
 like a standard driver would.

 That being said, I can't help but to think about others who may want to 
 publish data to Ambient as well. As mentioned on wxforum, the Ambient 
 documentation is kind of lacking for a developer and what the value names 
 are to submit (and how... GET vs. POST). But if there's a project that's 
 successfully posting data to Ambient, then maybe a weewx extension could 
 be 
 created to post to Ambient. An extension like the one for wunderground or 
 PWSWeather might be easy enough to fork for Ambient. This would save the 
 need of setting up and maintaining a node server (and help those here who 
 don't know what node is). The more complicated things get, the more 
 potential for something to break and you not catching it (like your node 
 server crashing and you don't know it for a few days). 

 I'm working on a skin for weewx now, but this could be a fun project to 
 think about - forking a PWSWeather 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

*I no longer am using my Ambient ObserverIP, so I don't have test data to 
use.* 

I do of course, so let me know if I could help in this regard.

On Tuesday, August 14, 2018 at 9:44:33 AM UTC-4, Douglas Krug wrote:
>
> *So maybe the thought here is to have your station submit to 
> AmbientWeather natively, and create a driver which gets the data from 
> Ambient's real-time subscribe system and submits it to weewx for archival?*
>
> Yes, that's the idea exactly! Ambient doesn't let you upload to their 
> server unless you buy a $150 license from them. But if you own their 
> equipment, there's no charge to upload. Since there's a way to subscribe to 
> Ambientweather.net via their API, there's for sure a possibility to bring 
> it into Weewx. In fact, there doesn't even need to be node servers and 
> routers passing the data, but I don't know how to code, so I wouldn't be 
> able to execute the concept. The ambient2pwsweather server is needed if 
> you're not running Weewx, but if you are, it's redundant since you can just 
> post to PWSweather from Weewx. It's the ambientweather.net piece that is 
> tricky due to their restrictions. However, everyone with any internet 
> connected Ambient Weather device and up-to-date firmware can upload to 
> ambientweather.net for free. So if there was just a way to subscribe to 
> data from ambientweather.net and bring it into Weewx, there would be no 
> need for Ambient Weather IP sniffing or listening, just an internet 
> connection, Weewx and a plugin.
>
> But I'm a home automation geek. I already have an always on Node.js server 
> running. I was reluctant to add another router, but I have several of them 
> and it was the easiest way to get data into Weewx. So adding another piece 
> to the puzzle doesn't phase me that much. It *can* all be so simple, but 
> it takes talented developers to do the work.
>
> On Tue, Aug 14, 2018 at 9:14 AM Pat  wrote:
>
>> Taking a look at the ambient2pwsweather project, it looks like he's 
>> really using the ambient-weather-api 
>>  project as his heavy 
>> lifting for ambient. And looking at the project it looks like what we 
>> talked about where AmbientWeather's API documentation 
>>  talks about how to subscribe 
>> to data, but not how to submit data. 
>>
>> So maybe the thought here is to have your station submit to 
>> AmbientWeather natively, and create a driver which gets the data from 
>> Ambient's real-time subscribe system and submits it to weewx for archival? 
>>
>> I've also upgraded to a Davis Vantage Pro 2, so I no longer am using my 
>> Ambient ObserverIP, so I don't have test data to use. 
>>
>>
>> On Tuesday, August 14, 2018 at 8:57:42 AM UTC-4, Pat wrote:
>>>
>>> The API into weewx would be a driver. Typically the weather equipment is 
>>> directly connected and the driver would control the weather station. That's 
>>> why I wrote the socket driver a few years ago because my equipment isn't 
>>> directly connected. 
>>>
>>> The good news is the interceptor driver has multiple ways to input data 
>>> into weewx, so it's probably as much of an API as you're going to find. By 
>>> sending HTTP data to the driver's web server, it can then pass it to weewx 
>>> like a standard driver would.
>>>
>>> That being said, I can't help but to think about others who may want to 
>>> publish data to Ambient as well. As mentioned on wxforum, the Ambient 
>>> documentation is kind of lacking for a developer and what the value names 
>>> are to submit (and how... GET vs. POST). But if there's a project that's 
>>> successfully posting data to Ambient, then maybe a weewx extension could be 
>>> created to post to Ambient. An extension like the one for wunderground or 
>>> PWSWeather might be easy enough to fork for Ambient. This would save the 
>>> need of setting up and maintaining a node server (and help those here who 
>>> don't know what node is). The more complicated things get, the more 
>>> potential for something to break and you not catching it (like your node 
>>> server crashing and you don't know it for a few days). 
>>>
>>> I'm working on a skin for weewx now, but this could be a fun project to 
>>> think about - forking a PWSWeather extension to the AmbientWeather service 
>>> - (unless someone else reading this wants to give it a try).
>>>
>>>
>>> On Monday, August 13, 2018 at 10:34:09 PM UTC-4, Douglas Krug wrote:

 Hello again Pat,

 Thanks for commenting. This is basically a continuation of the 
 conversation we had on wxforum. I've got experience setting up node.js, 
 that shouldn't be a problem. I stumble across the ambient2pwsweather node 
 project and reached out to see if he would consider modifying it. He 
 wasn't 
 really interested if there was no API for Weewx, which to the best of my 
 understanding, there is not. I suggested Matthew Wall's interceptor 
 plugin, 
 to 

Re: [weewx-user] Re: PWS data format for Interceptor

[Douglas Krug]

*So maybe the thought here is to have your station submit to AmbientWeather
natively, and create a driver which gets the data from Ambient's real-time
subscribe system and submits it to weewx for archival?*

Yes, that's the idea exactly! Ambient doesn't let you upload to their
server unless you buy a $150 license from them. But if you own their
equipment, there's no charge to upload. Since there's a way to subscribe to
Ambientweather.net via their API, there's for sure a possibility to bring
it into Weewx. In fact, there doesn't even need to be node servers and
routers passing the data, but I don't know how to code, so I wouldn't be
able to execute the concept. The ambient2pwsweather server is needed if
you're not running Weewx, but if you are, it's redundant since you can just
post to PWSweather from Weewx. It's the ambientweather.net piece that is
tricky due to their restrictions. However, everyone with any internet
connected Ambient Weather device and up-to-date firmware can upload to
ambientweather.net for free. So if there was just a way to subscribe to
data from ambientweather.net and bring it into Weewx, there would be no
need for Ambient Weather IP sniffing or listening, just an internet
connection, Weewx and a plugin.

But I'm a home automation geek. I already have an always on Node.js server
running. I was reluctant to add another router, but I have several of them
and it was the easiest way to get data into Weewx. So adding another piece
to the puzzle doesn't phase me that much. It *can* all be so simple, but it
takes talented developers to do the work.

On Tue, Aug 14, 2018 at 9:14 AM Pat  wrote:

> Taking a look at the ambient2pwsweather project, it looks like he's really
> using the ambient-weather-api
>  project as his heavy
> lifting for ambient. And looking at the project it looks like what we
> talked about where AmbientWeather's API documentation
>  talks about how to subscribe to
> data, but not how to submit data.
>
> So maybe the thought here is to have your station submit to AmbientWeather
> natively, and create a driver which gets the data from Ambient's real-time
> subscribe system and submits it to weewx for archival?
>
> I've also upgraded to a Davis Vantage Pro 2, so I no longer am using my
> Ambient ObserverIP, so I don't have test data to use.
>
>
> On Tuesday, August 14, 2018 at 8:57:42 AM UTC-4, Pat wrote:
>>
>> The API into weewx would be a driver. Typically the weather equipment is
>> directly connected and the driver would control the weather station. That's
>> why I wrote the socket driver a few years ago because my equipment isn't
>> directly connected.
>>
>> The good news is the interceptor driver has multiple ways to input data
>> into weewx, so it's probably as much of an API as you're going to find. By
>> sending HTTP data to the driver's web server, it can then pass it to weewx
>> like a standard driver would.
>>
>> That being said, I can't help but to think about others who may want to
>> publish data to Ambient as well. As mentioned on wxforum, the Ambient
>> documentation is kind of lacking for a developer and what the value names
>> are to submit (and how... GET vs. POST). But if there's a project that's
>> successfully posting data to Ambient, then maybe a weewx extension could be
>> created to post to Ambient. An extension like the one for wunderground or
>> PWSWeather might be easy enough to fork for Ambient. This would save the
>> need of setting up and maintaining a node server (and help those here who
>> don't know what node is). The more complicated things get, the more
>> potential for something to break and you not catching it (like your node
>> server crashing and you don't know it for a few days).
>>
>> I'm working on a skin for weewx now, but this could be a fun project to
>> think about - forking a PWSWeather extension to the AmbientWeather service
>> - (unless someone else reading this wants to give it a try).
>>
>>
>> On Monday, August 13, 2018 at 10:34:09 PM UTC-4, Douglas Krug wrote:
>>>
>>> Hello again Pat,
>>>
>>> Thanks for commenting. This is basically a continuation of the
>>> conversation we had on wxforum. I've got experience setting up node.js,
>>> that shouldn't be a problem. I stumble across the ambient2pwsweather node
>>> project and reached out to see if he would consider modifying it. He wasn't
>>> really interested if there was no API for Weewx, which to the best of my
>>> understanding, there is not. I suggested Matthew Wall's interceptor plugin,
>>> to just capture html traffic from the node server. He said it should not be
>>> too difficult, but wants info on how it should be formatted. You say it
>>> shouldn't be difficult, and that's cool. @mwall hasn't commented yet and
>>> I'm not a developer, so my understanding of it all is pretty rudimentary.
>>>
>>> I've got a lot of brilliant minds here, but the data is passing through
>>> me and