bpwwer

Sorry about that, I screwed up the syntax and since it was a simple change, I didn't bother to test it. version 0.1.8 does work.

I found the problem and version 0.1.7 should be available shortly. The unit configuration said to use 'US' for for imperial units, but all of my comparisons were checking for 'us'. I changed it so that it doesn't matter what case is used when configuring the units. Thanks for reporting the problem.

It looks like it should be reporting it. However, it only reports the reading to the ISY when it changes. If you look at the nodes in the polyglot dashboard. It's GV5 in the main controller node. Does that have a value that matches the data in the log? I think, because I tell the polyglot to only update the ISY when it changes, it's possible that upgrading the ISY, cleared the values in the ISY, but polyglot hasn't seen a change in the value so it hasn't sent an update. It works this way to reduce the load on the ISY. For a lot of my node servers I started forcing polyglot to send the values when the node server starts to as a way to work around this, but this one doesn't do that. I'll have to update it otherwise, you'll probably not see that update until you get more rain.

It should display the temperature in F. Did you try restarting the node server after changing the parameter and also restarting the admin console? The admin console will only read the node profile information once when it starts up and won't pick up any changes that are made to it until it is restarted again. I have seen some weirdness with the programming UI on the admin console where it will initially show the temperature as C, but the drop down actually has both units on the list, you just have to scroll it.

I don't believe the Ambient API provides rain rate data. There isn't any in the data you captured from the log. When I wrote this, the station I was testing with didn't have solar radiation so I had that commented out. I see it is in the data, so I enabled it and pushed a new version.

One of the problems I've had with the various weather node servers is that I don't always anticipate bad data from the service so sometimes bad data will cause them to crash. I've been trying to make them more robust and it helps to report why it crashed (from the node server log). However, in this case, socket failures could be a polygot/ISY failure or a nodeserver/DarkSky failure. I can'really only attempt fixes if it's a nodeserver/DarkSky failure. I do have a new version of the DarkSky node server (and OpenWeatherMap as well) that I'll be publishing shortly. These are based on the same design as the current WeatherBit node server.

Sounds like you may have installed it before I changed the name. You can try just installing the new version, I'm not sure if this will work or not. It may fail because of the different name. If not, you probably have to delete the node server from Polyglot, delete the WeatherBit directory from the polyglot machine (/var/polyglot/nodeservers for a Polisy, ~/.polyglot/nodeservers for local install). Then install it fresh from the store.

Yeah, it's all because of the name change. Basically, it installs but then since the name doesn't match, it doesn't know it was installed. However if you try to install it again, it fails because it's already installed. It's being removed from the store now so that I can re-add it with the new name. That should fix all new installs, but I'm not sure what that means for existing installs. Update: Looks like it should work fine with existing installs. If you refresh the store, it should now be called WeatherBit and it should have the "Uninstall" button.

I see the problem and will get it fixed shortly. Looks like set solar radiation to the wrong UOM in the profile files. The store may be because I changed the node server name. Originally it was WeatherBit.io, which was fine for Polisy and local polyglot, but not acceptable for the Polyglot cloud because of the '.' character. So I changed it to just WeatherBit. However, the store doesn't update the name in it's database. This seems to be a bug in Polyglot and I have no idea how to go about getting it fixed. It probably needs to be removed from the store and have me re-submit it. It will be interesting to see what happens when publish the update.

Ahh, I understand better now. Digging into it a bit more, I'm surprised that the livedata.cgi isn't returning the et0 data. It looks like it's on the SOL sensor along side the solar radiation. Can you check the node server log and verify that it's not there? You should see a debug line with the livedata result XML. That line should contain a SOL tag, mine looks like: <SOL date="20191217225618" id="sol0" rad="112" lowbat="0" />\n If you see an evo="xxxx" in there too, then it is available and I can easily parse it out.

I'm certainly not an expert on meteobridge usage. Can you explain how you did the rainmachine parser? Maybe that's better than what I'm doing now and I can update the node server to work is a similar way. I'm actually connecting to the meteobridge on TCP port 5557 to get the data, when making a socket connection to that port it outputs the same data I see from the livedata.cgi link. This seemed like the best way since it's easy and doesn't require any authentication to get at the data. I believe the livedata can be changed via templates, but I have't experimented with that at all.

The node server is getting the data from the livedata output from Meteobridge. From the documentation of that, I don't see any et0 values being output, but then the documentation is not complete either. Does accessing http://<your meteobridge ip>/cgi-bin/livedata.cgi so the et0 value? If so, can you send me that output so I can see what it looks like?

I'm sure there is, but I haven't looked into it yet. I was trying to make the node server mostly independent of the cloud services. It queries once at startup to get information like your units preference, but from that point on, it's just looking at the data generate by the hub on your local network. In this case, it's probably not a problem as the results can be considered optional, if the query failed to get the corrected rain data, you'd be no worse off. I'll add something to the TODO list for this. Thanks for the suggestion.

That message indicates that the service didn't send any data. Did you exceed the usage limits for the day? Looking it up, it looks like you can only query every 3 to 4 minutes and any more often and you'll exceed the 500 call limit. The node server is making 2 calls, one for current condition at the short poll interval and one for forecast data (unless it's set to 0 days) at long poll interval. I didn't check what the limits where so the default probably does exceed it. They should probably be set to 5 minutes and 10 minutes

I've been following this because I'm going to have a SolarEdge inverter soon and would like to use this node server after it's installed. So I took a look at your log. I think the problem is the way that polyglot (and specifically the cloud version) is handling the parameter update. The node server doesn't get the updated value after you enter it. Try doing things in this order: 1) Install the node server 2) Enter the api_key parameter key and value. Save the changes 3) Stop the node server 4) Restart the node server 5) Check the admin console to verify the nodes exist. You should see a SolarEdge Controller node, a Quackenbush1 node with two subnode for battery. Since you already have the key entered (per screen shot), just start with step 3, stop and restart the node server and it should discover your inverter.

I don't have any control over the order they get added. The node server is requesting them in loop, first to last day. Maybe if I added a delay between the requests it would be more likely to get them in order. Yes, my goal is to work on all the weather related node servers. I'm trying to make them a bit more maintainable by using more common code. The weatherbit node server was the prototype to separate out the weather service code from the node server framework code. Things like the log control & custom parameter support will simplify all the node servers some. It's just a matter of time.

I just added a new weather service polyglot to the store, udi-weatherbit-poly. This one pulls data from weatherbit.io weatherbit.io is similar to darksky and open weather maps. They have a free plan that works well. I did a complete re-design for this node server to try and make it more modular and separate out the node server framework code from the actual weather data processing code. I spent a lot time trying to get the custom parameter handling to work correctly as well. There are a couple of new features in this iteration: 1) added a command to the main node that lets you control the amount of log information the node server generates (thanks @Jimbo for the idea) 2) The number of days of forecast data is configurable. The service provides up to 16 days (including the current day) which is a lot of data to be sending to the ISY with each poll interval. Thus, you can now configure how many days you'd like to track. As I have time, I plan to work on converting both the darksky and open weather map node servers over to this design.

The ISY should handle the conversion, and note, that it's the ISY that needs to do that. The node server simply sends the data value and the units it's in. If you have version 0.1.8 you shouldn't need to re-install but you may need to update the profile (use the button that's available in the admin console display for the main node). Depending on if you're using it from the cloud polyglot or a local polyglot, updating and versioning is different. The cloud version will pull the latest version every time you re-start the node server, but it only displays the version number of what was first installed. I.E. you can't rely on the version number to know what version you are running. For a local polyglot you have to manually click an update button to update to the latest version, but the version number displayed will be the version you are running.

I just tried to clone a new node server I'm working on to the Polisy and got this error: sudo: unable to write to /var/run/sudo/ts/admin: No space left on device fatal: could not create work tree dir 'udi-weatherbit-poly': No space left on device A df of /var/polyglot shows [admin@polisy /var/polyglot/nodeservers]$ df . Filesystem 1K-blocks Used Avail Capacity Mounted on zudi/ROOT/default 5298048 5294859 3188 100% / Yes, the polyglot log file was huge and clearing it freed up about 45% of the space on the file system.

The missing data errors aren't really errors since it's not really a problem but more a way to check if something that should be there is missing. I just changed them to warnings, but maybe debug would be a better log level for those. The actual crash shouldn't be something new. It should have been doing that before but I guess since you were getting some data, you didn't notice. I've fixed that in version 0.1.8. This version won't require a re-install. On the Polyglot cloud, just restart the node server to get the latest. For local, just update from the store.

I just made a few more updates, including the ability to use the indoor sensor. Probably best to re-install again go get the new node files for the indoor sensors. With this version, you should now see a new custom parameter called 'indoor' by default, it is set to disabled. Change it to 'enabled' and restart the node server. It will then add a new node that has the indoor temperature and humidity.

I believe I have this fixed now. Currently, the node server is only really supporting imperial units as that seems to be only what the Ambient Weather API reports. I modified the node definition and editor files so that when using the node server's values in programs, you should get the option of what units to use. However, temperature is behaving oddly for me. When looking at one of the temperature values you get a drop down list that contains both Celsius and Fahrenheit. Other values like pressure will give you the option to select ingh or mb. Since the node definitions have changed, the easiest way to upgrade would be to delete the node server and re-install it. Otherwise the upgrade process is a bit more involved. Get the new version. On PGC, you can just stop and restart the node server to get the new version. For a local Polyglot you can update from the store. From the admin console, look at the main Ambient Weather node and use the "Update Profile" button. This will tell Polyglot to send the updated node definitions to the ISY. If you don't see this button then deleting and re-installing the node server may be the only option. Restart the admin console so that it re-reads the profile files and gets the new node definitions. On a different note. @simplextech and I were talking about combining our two Ambient weather node servers. For those of you that have tried both, what features do you like/dislike about each? Don't be shy it won't hurt our feelings. The goal would be to create one node server that takes the best of both.

I'm sure it's just the way I wrote it. This was one of the first node servers I created. I was using a test station from Ambient Weather, but they disabled it shortly after I wrote the node server so I don't have access to any data from them. I'll take a look at it and see what I can do to fix it.

The node server doesn't have the ability to change the units. My understanding (at least at the time that I wrote it) was that the Ambient API only provided the data in metric units. I don't have the node server doing any conversions. I don't have an Ambient weather station and don't have access to the API making it hard for me to support this node server.

The problem is not knowing the mac-id and my router doesn't let me access the list of dynamic IP addresses it's handed out. I did have to use arp to get a list of mac-id/IP addresses and then go through the IP addresses one-by-one until I found the one assigned to the Polisy. Once I found it's IP and Mac-id, it was no problem to add it to the router with a IP reservation and then add it to my local DNS server.