bpwwer

I did push up new versions of the other weather station node servers as well. I think the process that checks for new versions on the node server store runs once a day so give it 24 hrs.

@DaveStLou if I'm correctly reproducing the issue, then I think I have if resolved. When I query the node server, it switches the online status to false, but the WeatherPoly node server is not stopping, it continues to receive data and update the data nodes properly. It is only the online status value that is wrong. If that's the same behavior you are seeing, then what I just pushed (version 0.1.6) should resolve it. It looks like a bug somewhere in the node server interface. The node server starts with the status initialized to false, when it starts communicating with Polyglot, it gets switched to true. However when queried, the query seems to return the initial value, not the current value and thus, it's switched back to false. My change is to simply set the initial value to true.

Thanks, it looks like it's the thread that's failing. When I get my RPi back up, I'll see if I can reproduce it.

The problem is that we still don't know why it's going off line. The query seems to be what triggers it, but without actually knowing what is failing it can't really be fixed. Polyglot makes it easy to create a node server, but it also hides a lot of the communication from the node server developer. The WeatherPoly code isn't doing anything at all when the ISY does a query. The query is handled entirely between node server interface code and Polyglot. Can you provide anymore information about what happens when it does "offline"? The WeatherPoly node server has a separate process that listens for the incoming weather data and publishes it to Polyglot (and then to the ISY). Offline could mean that thread has crashed while the main WeatherPoly code continues to run, or it could mean that the whole WeatherPoly node server was killed. Next time it goes offline, can you run 'ps auxww | grep weatherstation' on the RPi and see if the node server is still running or not? And in either case, there should be some indication of what happened to cause it to go offline. My RPi is currently offline so I can't run any experiments myself. As far as I know, Polyglot doesn't have any way to automate node server start/restarts. Might be a good feature request for it though.

Ah, OK,, thanks. Working on the local install is a lot easier to debug. I rolled back all the changes I made trying to get it working on the cloud and then added my latest attempt. It seems to be working locally again, but I'm not sure about cloud. It does take some time for the store to notice the latest update. It should move to version 0.0.2 when it does. You'll probably have to delete your existing copy and re-install from the store once it's there. This is still pretty experimental, but should work.

I'm assuming you're trying to use the cloud based WeatherFlow node server. I've been trying to debug this for weeks and can't figure out why the cloud based polyglot fails to create some of the nodes. Right now I'm stuck and can't even start the debug environment for the cloud polyglot so no progress is being made. If you're not running this on the cloud based polyglot let me know. When I last tested, it did work with a local polyglot, but my debugging efforts for the cloud may have caused some issues.

The log indicates that the node server is trying to add the nodes to the ISY, but it's not happening. The node server sends the request to Polyglot and Polyglot is supposed to send the command to the ISY to add the node. If Polyglot thinks the node already exists on the ISY, it won't try to add it again so that's the only thing I can think of that would cause this. Manually clearing the Polyglot database should have solved it. Possibly it is sending the command and the ISY is rejecting it for some reason, but that should show up in the Polyglot log. The fact that the nodes aren't showing up in Polyglot dashboard also points to Polyglot thinking they've already been added. My next suggestion was going to be to try and install it in a different slot. But now that you have things mostly working, it's probably not worth it to keep experimenting. I'm sorry it's been so much trouble. Most of the time it just works, except when it doesn't.

I don't see anything in the logs that indicate an issue so my only guess at this point is that the Polyglot database is corrupt for that node server slot. I've seen this type of behavior before where the database entries don't get cleared out properly and Polyglot thinks the nodes are installed on the ISY so it never tries to add them. Even after deleting and re-installing the node server. I think this may be related to a bug in Polyglot and unfortunately the only way to really fix it is to uninstall the node server, manually clear out the database and re-install. The command to clear out the slot in the database is: mongo polyglot --eval "db.nodes.remove({'profileNum':'6'})" Where the profile number (6 above) is the slot where the node server was installed.

No, not with the existing node servers. So far, I've concentrated on creating node servers that get data from locally installed home based weather stations. However, I've also started working on one for openweathermap, but it's not finished yet.

Ok, I made the same change so it should work now, but I don't have time to test it right now. I pushed it anyway since it's not a complex change. I've considered irrigation requirements calculations, but they are pretty complex so I haven't looked at doing anything with them yet.

It's showing the data as Ambient sends it. I'm not doing any conversions in the node server. It's something I can add but it's a bit of effort so may take a while.

Log into your ambientweather.net account and select your account info (person icon or maybe your avatar at the upper right corner). There should be an API Key section at the bottom with a button to create a new API key. You create API key's to allow applications, like the node server, to access your weather data.

Looks like it's there now.

Yes it should. I'm not sure what the frequency is, but it shouldn't take more than a couple of hours before it shows up.

Thanks, I didn't realize there could be qualifiers on the trend. I added that, but it does mean the profile data in the ISY needs to be updated. I'm not sure it will do that automatically when updating to the new version.

Thanks. The AC doesn't always like having the nodes redefined on the fly, I'm not sure if there's a way around that.

When you say MeteoBridge above, are you referring to the node server/ISY display or the actual MeteoBridge web interface? Ah, I think I see the problem, the MeteoBridge is sending the value in m/s and I think I'm assuming metric is kph for the conversion so the conversion to mph is wrong. Otherwise, it looks correct. I'm not sure that the MeteoBridge is sending what it says it is though. It looks like it's sending average wind speed and current wind speed, but reporting current wind speed as gust. It is sending two values labeled as "wind" and "gust" and the mapping to the ISY matches those values. I just uploaded a new version with the conversion fixed.

It's actually the ISY that expects numeric values. There currently isn't any way to have node values be strings. However, we can map the numeric values to strings for display. I may have fixed the bug and I did add some code to map from Cumulus pressure trend strings to node integer values. Let me know if that works. If not, I need to see the log message just above the errors you got above It should be something like "Set pressure driver GV1 to Falling" I think.

I suspect that the query causes a bit of network congestion, just enough that the server connection times out and fails. Or it could be something blocking in the node server to polyglot interface long enough to cause the timeout and failure. Have you tried restarting the node server after making the configuration change? It looks like I have it handling additions and changes to the configuration at runtime, but it doesn't actually delete at runtime. That's a bug. A restart will start from an empty list and only create the nodes that match the configuration. So that should work around the bug.

Hi Tim, Well, at least it's working. Sorry that the install process was so messed up. I'm working making that better and not just for this node server. Switching units does work, but the options are 'metric', 'us', and 'uk'. I just added a configuration help file that explains that. I should have done that a while ago. It sounds like what you probably want are 'us' units. At some point I'll look at making the units selection more configurable. I've always seen that same warning about Cipheriv and have never bothered to look into what it means. I suspect it is using some slightly older encryption method for the https frontend connection.

So based on the log it looks like the node server is running and parsing correctly, it's now Polyglot that has issues. There are a few bugs in Polyglot where it can get confused when deleting and re-installing node servers. If everything goes smoothly the first time, all is good, but as you've noticed, if it doesn't... The main issue seems to be that polyglot doesn't always clean up it's database and then when re-installing, it skips steps because it finds the old data in the database. The only way I know of to clean this up is to manually remove the data from the database. These are the steps I would try: Stop and delete the meteobridge node server Run the command below (profileNum is the slot number the meteobridge node server was installed in). I believe you need to use the same account that runs polyglot to run the command. mongo polyglot --eval "db.nodes.remove({'profileNum':5})" Then re-add the meteobridge node server. It should now create the nodes. I've been working on resolving some of these issue with Polyglot so it won't be such a hassle in the future.

I think the problems are all caused because the profile/nodedef directory doesn't exist. I just pushed version 0.1.2 that should have a fix for this. Try updating and if that doesn't fix it, then create the the nodedef directory in .polyglot/nodeservers/MeteoBridge/profile and restart the node server. If that still doesn't work, you may have to delete the node server and re-add it.

Is there anything in the node server's log for that time? That message doesn't mean a whole lot. When Polyglot sends a request to the ISY, it does so in a loop so it will make a number of attempts. This message just tells us that an attempt failed but at some point, before it reached the max number of attempts, it did succeed. There are a few possible causes. It could be that the ISY was too busy to respond or it could be a router issue, or cable issue, or network interface issue. The actual error basically, it means that Polyglot never got a response from the ISY. The node servers are also communicating with Polyglot over the network so it's possible that they are also encountering the same issue but instead of re-trying, they just fail.

I think it goes off-line when the connection between the node server and Polyglot drops for some reason. I've had some weird cases (usually when Polyglot is killed and the node servers stay running) where it loops connecting and disconnecting, but not a case where it just drops. In this case, I would look for the node server actually crashing which should leave some indication of what happened in the node server log.

Ok, I think I found the cause. It looks like there's an entry for the node in the polyglot database but the profile number is NULL. So when polyglot queries the database for the node by address, it find it, thinks everything is OK and continues. I've made a small change to polyglot so that in this case it now returns as if it didn't find the node, which causes it to update the database entry with the profile number and create the node on the ISY. One way to resolve with an existing setup would be to delete the affected node server and then run mongo polyglot --eval "db.nodes.remove({'profileNum':null})" to clear out the bad records from the database.