bpwwer

No, there isn't anyway to work immediately after a reboot. It only does the calculation at midnight, because that's when it has the all the data it needs to calculate it. mm/day is the default units, it will (or should) change the correct units when it next updates the value. Only by making the window bigger. The node server has no control over that, the display is all up to the admin console.

Seems to be working fine for me. I created variables for temperature, hub seconds sine seen, and eto and all had the right values when I manually ran the program. New Program - [ID 0008][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $Weather_Variable = 'WeatherFlow' Hub Seconds Since Seen second $Int_2 = 'WeatherFlow / AR-00012631' Temperature °F $Int_3 = 'something / somethingelse / WeatherFlow' Yesterday's etO inches/day Else - No Actions - (To add one, press 'Action') I have two copies of WeatherFlow installed so I mixed it up and used both.

I screwed up trying to add something new to the startup script. I thought I'd have a few minutes to get it fixed before anyone tried to update, but man you guys are fast!

I believe those are normal. I'll need to revisit how I handled this, but on start, it clears out all the nodes before it adds back the ones it needs. These messages are generated when it tries to delete nodes that don't exist. This is because the configuration determines which of the set of possible nodes need to exist. I wanted to make sure nodes didn't get orphaned if the configuration changed.

@macjeffNot your fault. Different node servers do different things and I can only test with some of them. I also tend to test just what I think I'm changing so sometimes I miss things. I was actually thinking of getting a Wireless tag or two just so I could test, but didn't, at least not yet.

Yes, I noticed this too and it'a a bug (sort of). Every 8 hours it refreshes the contents of the store and updates it's internal cache of that info. So what is being reported is the last time that cache was refreshed, not the last time it was modified in the store. So yes, that needs to be fixed.

Is Elk the only node server now having issues? Try going to the ELK details, selecting log and change the log level to something different, then restart the node server.

I pushed out 3.0.51 that should fix the problem, but I've been waiting for confirmation of that. I was not able to reproduce the issue with any of the node servers I have installed for testing. I suspect there was a case where I expected data from the store that many existing node servers haven't updated yet. 3.0.51 should work with those older entries.

The ability to install node server that aren't in the node server store was there for node server developers. @jjcif you are a registered node server developer, the new process for node server developers has been discussed on the Slack channel for PG3 node server developers. Whether or not this feature is opened back up to non-developers hasn't been determined.

Maybe this:

Yeah, I'm seeing all kinds of weird behavior too. When I send the "STOP" command, my volumio is responding that it is stopped, then with the next update it responds that it is paused. Which matches what I see on the AC. It briefly displays stopped before switching to paused. I've also managed to get into a state where it is playing, and won't stop/pause. If I send the commands directly from the browser, it responds that the command was successful, but it just keeps playing. I have to send a 'play' and the stop/pause will work. When you say the ISY doesn't show he current status of repeat/shuffle, is that in both the upper status display on the AC or on the lower command section or both? I'm not able to reproduce that, both sections seem to reflect the correct status for me.

Version 2.0.3 should fix both shuffle and repeat command.

Yes and no. Polyglot is an application. It manages node servers. Node servers are also applications, they just happen to be started and stopped by Polyglot. Node servers are independent entities. So technically, the node servers boxes should be outside of the Polyglot rectangle. Also, node servers don't link to ISY, your Link B, they route everything through Polyglot. The way PG2 and PG3 implement connection status is different. With PG2, the node server connects to PG2 and sends a connection status as part of the initial connection handshaking between the node server and PG2. In this case, connected means that the node server has successfully connected to PG2. This connection status is held in the node server's controller node's ST driver which is sent to the ISY. With PG3, when a node server connects to PG3, PG3 marks that node server as connected, when PG3 stops a node servers, it marks that node server is disconnected. If the connection between PG3 and node server fails, PG3 marks that node server as failed. This is all internal to PG3 and is what PG3 displays on the dashboard and node server details. THIS IS NOT SENT TO THE ISY! However, the node server has the option to configure a node and driver as a connection status indicator and IF it does so, PG3 will automatically update that node/driver with the connection status and send the update to the ISY. Note that in all of the above, the only thing we are monitoring is the connection between the node server and Polyglot. If the node server wants to track the connection status between the node server and service/device it can do so, but there is not standardized way for it to report this, it would have to designate a node/driver to hold this information and report it to the ISY. Also note that there is nothing that is tracking the connection between Polyglot and the ISY. If there are failures in that communication, the only indication will be errors reported in the respective log files.

Have you tried enabling the java console and starting the admin console for the ISY? If the ISY has issues parsing the profile files, it should log those to the java console. There shouldn't be any difference in the ISY vs. IoP parser but given that IoP has been getting a lot of updates recently something may have been fixed that and not in the ISY firmware.

I wonder if the recent package updates to Polisy made things better? I'll check on my end.

This is the backup/restore Poly for the Universal Devices ISY994i Polyglot interface with Polyglot V3 (c) 2020,2021 Robert Paauwe This node server takes a snapshot of the lighting type device status and can then later restore the devices to those values. Lighting devices are those devices that have a status value using the unit-of-measure for level (0-255) or percent. This should cover most Insteon switch/lamp modules and Z-wave switch/lamp modules.

The big difference in this version vs. the previous version is that the operation to create the zip archive is a blocking operation. I.E. while it is running, PG3 does nothing else. This makes it quite a bit faster, but also causes the UI and it looks like the node servers to loose their connection to PG3 thinking PG3 is down. I'll keep looking for a better solution to this.

Ok, thanks. I didn't notice any node servers going into failed state when I tested, but I may have had them stopped at the time. I'll try again to see if I can reproduce what you're seeing.

If it took a while, that's probably because you have a lot of large log files. That's also probably why the node servers went into failed state, PG3 was too busy doing the backup to talk with the node servers and they gave up. I'd like to have it skip the log files and not back those up, but the libraries I've tried, don't seem to support that. You should have been able to simply start each of the node servers without restarting PG3.

Something has changed in the python module dependencies that that it uses but I haven't had time to figure out what. I think I fixed it so that pyemvue now loads, but something it needs is now failing for me.

As it's being used to day in PG3, connection status is reporting the connection status of the socket connection between the node server and PG3. This is monitored and reported by PG3, not the node server. If that connection is alive, PG3 reports 'connected'. Depending on how the connection is closed, if by PG3 stopping the node server: 'not connected'. If by the node server crashing and dropping the connection: 'failed'. However, in the node, the connection is maintained by a thread while other threads are used for other tasks within the node server (say to maintain a connection with the hardware it supports). Thus it is entirely possible for the some parts of the node server to fail while the connection to PG3 remains alive. Also, node server don't have to make use of the PG3 connection status. At this point, I believe almost all node servers that report "Node server Online" are using the PG3 connection status, but I'm not sure. Node servers could report the connection status of their connection to external devices but if they do, I would think they'd use a different name for that.

There are no custom typed configuration parameters for this node server.

Just to add some clarity, there is not an error "db_getNodeDrivers: controller not found in database". That is a WARNING. It may or may not indicate something is wrong. It is more of an informational message for node server developers. There are cases where not being able to find something in the database could be the reason for something not working as expected and there are cases where this is normal. In this case, since it happens right at the start, it most likely is because the database that it's checking has not yet been loaded and is empty so it is an expected warning. Remember PG3 is in a alpha state. There are going to be a lot of log messages that won't be of much use to users but are there to help developers debug.

I think you're seeing the difference between historical data and current data. The node server is always showing current data and only current data with the exception of rain accumulation (month, year, etc). I believe both remote and local get the same data over the last 1 minute interval. So the node server is only reporting data obtained over that 1 minute interval. I don't have any insider knowledge about how their app works, but they very well could be showing the last lightning strike detected vs. any detected in the last 1 minute. The node server is designed to allow you to trigger off of and make decisions on the current data. Where something like the app is designed to show what's happened/happening. Different goals. When configured for 'remote' data, all data comes from the WeatherFlow servers.

Sure. I'll add that to the TODO list for that node server.