bpwwer

Just pushed a new version that moves the indoor conditions to a separate node. Also, it will only create the indoor node if indoor data exists. I added processing for soil conditions too and again, will only create a node for those if the data exists. It looks like yours doesn't send any soil conditions (probably needs additional sensors or something). If everything looks good after you've had a chance to test a bit, I'll submit it to the Polyglot store so others can use it too.

I updated rain to be inches instead of counts and pushed the change. I'm thinking of moving the indoor temp/humidity to a separate node. Then I can add the other indoor values there as well, That will de-clutter the main node some. I can also add the soil readings in a separate node.

I have something wrong with wind speed, I had it working at one point, but then broke something. I'm not sure why the indoor readings aren't showing, everything looks correct there, I'll double check that. The daily rainfall value is in something called 'counts'. I'm not sure what that really means. Maybe it's the tipping bucket count? If I knew what one count equated to in inches or mm I can do the math and report an actual value. Any clue?

Gary, I pushed a new version that includes more data and should fix the problem with it crashing. To update it 1. stop the WeatherLink node server from the polyglot dashboard 2. from your PI terminal window do the 'git pull origin master' 3. start the WeatherLink node server 4. from the admin console, click the 'update profile' button for the WeatherLink node 5. restart the admin console Some of the things you list above aren't available, at least not in the sample data I have. If you can post/attach the log showing the results of the query, that would help. It should look something like: 2019-07-30 16:07:15,003 [NodeServer] [DEBUG] {'error': None, 'data': {'ts': 1531 754005, 'did': '001D0A700002', 'conditions': [{'rainfall_monthly': 63, 'wind_dir _at_hi_speed_last_2_min': 0.0, 'wind_speed_avg_last_2_min': 42606, 'rain_storm_l ast': None, 'lsid': 48308, 'rain_storm': None, 'heat_index': 5.5, 'wind_chill': 6.0, 'rainfall_last_60_min': None, 'temp': 62.7, 'trans_battery_flag': 0, 'rain_ storm_start_at': None, 'wind_speed_hi_last_10_min': 8, 'rainfall_last_15_min': N one, 'rx_state': 2, 'wind_dir_scalar_avg_last_1_min': 15, 'rain_size': 2, 'wind_ speed_avg_last_1_min': 4, 'rainfall_last_24_hr': None, 'dew_point': -0.3, 'data_ structure_type': 1, 'rain_storm_last_end_at': None, 'txid': 1, 'wind_speed_last' : 2, 'wind_dir_last': None, 'wind_dir_scalar_avg_last_2_min': 170.7, 'rain_rate_ hi_last_15_min': 0, 'rainfall_year': 63, 'solar_rad': 747, 'rainfall_daily': 63, 'hum': 1.1, 'rain_storm_last_start_at': None, 'uv_index': 5.5, 'wind_dir_scalar _avg_last_10_min': 4822.5, 'wind_speed_hi_last_2_min': 8, 'rain_rate_hi': None, 'thsw_index': 5.5, 'wind_dir_at_hi_speed_last_10_min': 0.0, 'wind_speed_avg_last _10_min': 42606, 'thw_index': 5.5, 'rain_rate_last': 0, 'wet_bulb': None}, {'moi st_soil_2': None, 'data_structure_type': 2, 'moist_soil_4': None, 'txid': 3, 'ls id': 3187671188, 'wet_leaf_1': None, 'temp_4': None, 'wet_leaf_2': None, 'moist_ soil_1': None, 'temp_1': None, 'temp_3': None, 'rx_state': None, 'trans_battery_ flag': None, 'moist_soil_3': None, 'temp_2': None}, {'data_structure_type': 4, ' lsid': 48307, 'temp_in': 78.0, 'heat_index_in': 8.4, 'dew_point_in': 7.8, 'hum_i n': 41.1}, {'data_structure_type': 3, 'bar_trend': None, 'lsid': 48306, 'bar_abs olute': 30.008, 'bar_sea_level': 30.008}]}}

Can you be more specific about what is not updating? Did you get the 'git pull origin master' command to work? Is it it the field labels that still aren't right? Is it not updating the data on the ISY? Is that log current or just what's there from the first time you started it? From what's shown there, the IP address of the WeatherLink device hasn't been set, but the screen shot you had from before seemed correct.

Yeah, you just manually installed it the same way the store does. The 'cd udi<tab>' should work there. To update a non-store based node server (or even one installed by the store) manually. You get into the directory for the node server and use the 'git pull origin master' command. That the same thing that will be run when you update from the store. You can check if you're in the right place with the 'pwd' command. Here's what it looks like for me: $ pwd /home/pi/.polyglot/nodeservers/udi-wll-poly $ git pull origin master From github.com:bpaauwe/udi-wll-poly * branch master -> FETCH_HEAD Already up-to-date.

It should be the same directory that was created when you did the git clone initially. So if you haven't tried anything else yet, your command window should still be in the nodeservers directory. the 'ls' command will show everything there and you can skip the whole path and just 'cd udi-wll-poly'. Another trick is that you can usually use the <tab> key to do auto completion. So typing 'cd udi<tab>' may fill it out automatically. If not, <tab><tab> should show all the possible matches for what you started to type. Yes, currently it's polling for the current conditions. If I'm reading the docs correctly, the live streaming of data is only wind and rain and can only be run for fixed lengths of time. If you have some documentation that says otherwise, can you point me to it?

So it worked. Looks like I didn't update the profile files so that's why the data field names don't match/make sense. To get the update: cd ~/.polygot/nodeservers/udi-wll-poly 'git pull origin master' It should grab the latest code from the repository Then from the admin console press the "Update Profile" button and it should update the field names. You might have to restart the admin console before it will see the changes.

What you typed above looks like there's an extra '/' character at the end but that shouldn't matter, it works for me both with and without that. Can open it with your browser? The error means bad request, but I don't see anything bad about it. It's the same command used by Polyglot so if you've been able to install any node servers it should just work. I'm sure you entered it correctly, but can you cut-n-paste the command or is that not something you can easily do with your configuration?

Does that mean you can't actually query it unless it's on Wi-Fi and the app is running? If so that's a strange bug. Have you actually tried pointing a browser at it? The docs I have say it should return current condition data at http://<it's ip address>/v1/current_conditions If you get data there, the the node server should work. You can install the node server with the following steps on your RPi. 1. cd ~/.polyglot/nodeservers 2. git clone https://github.com/bpaauwe/udi-wll-poly 3. from the polyglot web interface -> NodeServers -> Add NodeServer 4. select "WeatherLink" from the list of available node servers and add it. The only configuration is to add the IP address in the custom parameters. Once that is entered and saved, it should start doing queries every minute to get the current conditions. Log information will be in ~/.polyglot/nodeservers/udi-wll-poly/logs/debug.log

@garybixler I have a test version running using some sample data I was able find on-line so let me know when you get the hardware setup and I'll get you started on it. Right now it's just grabbing some of the current condition data and I've not tried to access the 2.5 second UDP data. Also, there are a lot of different wind / rain values available, I'm just pulling the basics so you'll have review them and see if there's anything else that would be useful. The node servers also have to be written properly to work this way too. I'm not sure all of mine are. But even so, some of the weather data, especially when it is coming from a local station, can vary slightly with every update. So something like 2.5 second wind speed/direction readings are very likely to change a lot unless it's a very calm day.

I see two different ways to access the data. 1) is by connecting locally to the a WLL device. With this method, current conditions can be polled fairly frequently (10 seconds) and it can also be set up to broadcast some data (wind and rain) every 2.5 seconds over UDP. This is what I was looking at using. With the initial version just polling for current conditions (probably at something more like 1 minute intervals just to not overwhelm the ISY). Setting it up to get the UDP broadcast would be dependent on use case requirements (I.E. do you see a need for that data at that interval?). It sounds like this is what you're looking for too. 2) is to connect to the WeatherLink server over the internet. The polling interval for this is much longer (15 minutes?). This also has a dependency on the internet. However, it could also be run from a cloud base Polyglot. Based on what I found, it sounds like they are updating the API for this method with the new API expected later this year. I'd rather postpone any work related to this until after the new API is releases, if something like this is desired. Do you have a local Polyglot set up? And if so, are you comfortable installing a node server from the command line?

Hi Gary, I don't believe anyone has created one yet, but from what I found searching on-line, it seems like it would be pretty similar to the WeatherFlow node server that I wrote. I don't think it would be too hard, but without direct access to a WL device, it can be a bit time consuming to debug issues getting getting it working. If you're willing to spend the time testing and providing feedback, I'll be happy to create one.

Did a bit more with the new module last night. I associated a Zooz water valve and it worked great. I then created a scene and controlled the value with an Insteon switch. I also re-oriented the ISY to vertical but still have issues communicating with my multi-sensor. The sensor is quite far from the ISY (and farther from any other z-wave device) but it did work well with the old module/external antenna combo.

Installed the board to day and no issues with the installation. Initially, there were some issues with both my Kwikset lock and Aeotec multi-sensor. A network heal seemed to clear up the problems with the lock. I ended up removing and re-associating the multi-sensor. And while the multi-sensor did re-associate, it still seems to be having issues. I suspect it is simply that the range isn't as good as I was using an external antenna with the old board.

Just so you're not feeling completely alone, I agree with you. In my HomeSeer plug-in, I track scene state and allow for state change events. I do it based on the Insteon definition of a scene which is a set of devices set to specific values. The ISY knows that information as my plug-in gets that info from the ISY. Then any time a device changes state, I check to see what scenes that devices is a member of and check each of those scenes to see if all the devices in the scene match the "scene definition". If they do, the scene is ON and if one or more don't, the scene is OFF. As far as I'm concerned, it doesn't really matter how the scene got turned on or off. I you went around and set each device manually to the values specified in the Insteon scene definition, then the scene is ON. But that's just my opinion. Not everyone has the same definition for what a "scene" is and thus we see many different interpretations of how to handle various cases and events. Because all of these different interpretations are neither wrong or right, UDI has no clear direction for how implement scene status/state. Seems like about once a year someone brings this up.

WeatherFlow is pretty open about access to the station data. They have a "hub" that collects the data from the sensors and then sends that data out over a number of different channels. One is via BLE to smartphone/tablets. It also sends the data via WiFi to WeatherFlow servers where it can be accessed via a published API and it sends it via WiFi to your local network as UDP packets (also well documented) so local applications can directly make use of it. I've created a node server application that takes that data and feeds it the ISY so that ISY programs can use it to control other things. For your application, the WeatherFlow station has a nice feature where it can send out "rapid wind" updates. These are sent every 3 seconds. With that you'd be able to detect gusts immediately and start rolling up the awning. There are other personal weather stations that could provide similar capabilities, but would likely require some development to get the same integration with the ISY. For example, I have an Acurite 5-n-1 system today with some additional hardware and a program I created, I have it simulating the WeatherFlow data to have it integrate with the ISY. Acurite is not nearly so open with their station data and one of the reasons I have a WeatherFlow station on order. The one downside to the WeatherFlow station is that today is the last day to pre-order it and you'd have to wait at least 30 days for it to ship.

Sure, to the rainmachine or nodelink? I won't be able to do it until a bit later tonight, but I can PM you the info.

And for some reason the last post lost more than half of what I wrote I logged the connection with my HS plug-in and get the following. You'll notice that the response from my HW version 1 box is different from what a newer box will return. Is is possible that your response parsing is failing on this? I know I had issues with it when trying to get my code working on a newer box. If you want me to try pre-release versions to help debug, let me know. RainMachine HW version: 1 SW version: 3.74 API: 3.64 Attempting to authenticate with https://192.168.92.56/api/4/auth/login Got response: {"statusCode": 0, "access_token":"NMAMFMCMPAAGAJMA", "expires_in":157680000 }

After a restart the error changes but still not working 2018-02-09 09:20:23 - ISY NodeLink Server v0.9.5 started 2018-02-09 09:20:23 - Web config server started (http://192.168.92.205:8090) 2018-02-09 09:20:23 - ISY resolved to 192.168.92.26 2018-02-09 09:20:23 - ISY Node Server config detected (profile 1) 2018-02-09 09:20:24 - Warning: nodesetup.zip file needs updating in ISY 2018-02-09 09:20:29 - RainMachine Login Error - The remote server returned an error: (400) Bad Request. [rain1]

With 0.9.5 it does accept the port number but now I get: 2018-02-08 15:22:00 - RainMachine Login Error - The underlying connection was closed: The connection was closed unexpectedly. [rain1] I don't know if this helps, but with my HS plug-in I'm connecting to: https://<ip>:443/api/4/auth/login and posting: { "pwd":"<passwrd>", "remember": 1 } I'm using C# and have to also handle the invalid certificate and force disable the Expect: 100-continue header to get authentication working. I believe my code works for later RM modes also although my sample size is very small (1 new generation RM)

Thanks! I'll give it a try later today.

With 0.9.4 I'm still having issues getting it to connect with my 1st gen. When I enter the ipaddress:port I'm getting a tooltip message that says "! Please match the requested format" I'm entering 192.168.92.56:443 so I'm not sure why that doesn't match the requested format. Am I missing something? If I go with just the IP address, it accepts it but I'm getting: 2018-02-07 17:06:52 - RainMachine Login Error - Unable to connect to the remote server [rain1] I know it's possible to connect and interact with my rainmachine with local authentication as I have a HomeSeer plug-in that works with it.

Nothing is wrong. A little background... A long time ago, when I added support for variables, I had the plug-in query for additional variable types thinking that UDI would add some additional types beyond the two integer types. By querying for other, not yet defined, types, I thought it would make the plug-in a bit more future proof. Recently, I tried to improve some of the error reporting and that improvement happens to catch the case where it queries for the undefined variable types and gets an error back. It's always done this, just now the message makes it sound more dire than it is. Every time I start the plug-in now, I think that I should fix that, but since it doesn't effect the operation, I've been putting it off. It will be fixed in the next release.

I don't think so. I had a computer attached and it always read -19w. I think it's still doing that, I haven't looked in quite a while.