bpwwer

Thanks! Hopefully I won't break it while fixing all the things I broke on the RNET side.

There are pros and cons to restarting PG3x often. If the node servers are having issues and not properly recovering from errors (which is really a bug in the node server), then restarting them may mask/hide the problem. However, it's always best to try and work with either the node server author or UDI to get the node server bugs resolved, that helps everyone. However, when PG3x starts, it has to start up all of the node servers which happens in a fairly short period of time. In most cases, the node servers then try to update all of their data so the IoX gets blasted with everything all at once. Depending on the node servers and number of node servers, this can overwhelm the IoX, possibly causing it to drop incoming connections. In some cases, this can cause more issues with the node servers. We've tried to minimize the start up issues, so normally this isn't a problem, but we've designed the system with the assumption that PG3x will typically only be restarted infrequently. Given the 119 node servers that are now available, I'm only running a few of them. But my Polisy was restarted for the first time in many many months about 3 days ago when we had a power outage that outlasted the battery backup.

The list of sources (and other names) in the config data is just a fixed size array of characters. Russound does not provide any documentation on what or how data is stored in the config data block. I've had to reverse engineer that my self. When the node server looks at the names, it just reads the characters from that fix size array until it sees a null (value 0) character or it hits the size limit. So if it's showing "SonosName6", that's what's in that field. There might be something in that config data that says it should only use the first 5 characters, but I don't know how to get that info from the config if it exist. Best I can offer is to make sure the fields are cleared out using the Russound config tool. The TCP error usually happens when a command is sent to the node server but the IoX times out waiting for a response. This will happen if 1) the node server isn't ready for the command or 2) the node server doesn't recognize the command The errors in the log seem to be related to timing again. It seems like the CAM is taking much longer to respond to command than my CAV does and thus, the node server is asking for stuff too quickly before the zones are fully configured. Looks like the source indexing is off by one. Version 2.1.3 fixes the source indexing and should delay some of the operations until the zone nodes are configured.

Actually, you do. I use IcedTea with Fedora Linux and have it configured to always open the console when I launch the Admin Console. I don't remember how I configured it to do that, but google probably knows. I seem to remember adjusting memory limits as well, but I'd need to google how to do that as well.

No, it only communicates with the server. The WeatherLink node server gets data directly from the console.

I'm not sure what's returned in the data request. It may be that the app is doing something with the data and you'd have to create programs on the ISY to mimic that behavior.

Should be fixed in 2.1.2 that's in the store now.

I've made a beta version of a node server that uses the V2 API available for initial testing/feedback. The version 2 API is very different from the version 1 API. It organizes the data differently and node server node organization changes to match the API. The node server first queries for the list of stations associated with your account. For each station it finds, it creates a "station" node. It then queries for the list of sensors and sensor data reported by each station. It creates a node for each sensor associated with the station. These nodes are grouped with the correct "station" node and are named based on sensor product name. Support for different Units is still missing in this beta release. For some data (rain for instance), the data is available in both US and Metric values, but for most, it seems to only be available in US units. Since this is a new node server, you can run it in parallel with the existing production WeatherLink node server.

Yes, comparing the times between your CAM and my CAV, your CAM is sending packets at a much slower rate. I suspect this is related to the baud rate setting. I'm using 19200. In your case, it was timing out while trying to get the config data which explains why most things didn't work. I've increased the timeout so it should work now. The downside to increasing the timeout is that it now takes more time to determine how many controllers are connected. As the only way to detect is a controller is to attempt to get the config data. If it times out trying to get the config data, then it assumes there isn't a controller at that controller ID. Version 2.1.1 has the increased timeout and is in the store now.

Based on what I'm seeing the log I'll have to do some investigation. It almost seems like the CAM is slower at providing the initial info than my CAV is and that's causing some issues.

Post here or PM, doesn't matter to me.

Always check the log files. Most node servers don't try to report errors to the UI and rely on the log files as the main method to report any issues they encounter. If possible, always download a log package and include it when reporting node server issues. Unless the issue is obvious the node server author, they will almost always request the log package. From the description, it sounds like the node server is unable to connect to the CAM (or itach). I don't understand what you are trying to report about programs. A program condition can be an "and" or an "or", there isn't an "if" option.

WeatherFlow doesn't report the actual lightning sensor data to the app. What they report on the app is something they generate by looking at more than just your sensor. The node server, when configured to read data from the local device, reports just what the local device reports. For the rest of the data, this should be the same, it's just the lighting data that can differ. The lightning data is also a bit different in that I think the app shows the last lightning strike data, the node server reports the last thing the sensor reports. From your app above, it shows the last strike was 7 minutes ago, the node server is displaying the current data reported by the sensor (not the data reported 7 minutes ago).

That sounds more like an issue with the API than the node server, but I don't own any Sonos devices and can't attempt to reproduce or test. The node-sonos-http-api library has 161 open issues, if you can reproduce the issue using just the API, you can enter an issue with the library. However, it appears that the maintainer is only updating the library when someone sends an actual bug fix to him so just opening an issue may not get any resolution. If you can trace the issue to something the node server is doing wrong, I can take a look and attempt to fix it. However at this point, I believe the node server is simply calling the join API with the two devices so there's little chance that the node server is doing something wrong. When the node server log is set to debug level, it does output some information about what it is doing when you do the Join. Maybe that would help.

One has an 'x' at the end of the name PG3x started as an experiment to see if we could use an external MQTT broker instead of the internal broker library being used in PG3. There were some reported issues that we believed were caused by bugs in the internal MQTT broker library code. This was basically an internal change with no change in functionality. Once we were certain the external MQTT broker would work, it made it possible to do some things that weren't really possible before. Run node servers under separate/unique user accounts for additional security Allow for remote access (currently used by UD Mobile) to PG3 Allow node servers to access remote authentication mechanisms (Ring) That's really it for differences. Everything else remained the same. As of PG3 version 3.1.23, UDI is no longer maintaining PG3. Bug fixes and new features have only been applied to PG3x. Many of the features are targeted at node server developers but there have been a few UI enhancements in PG3x. I've been maintaining the PG3 code by applying all the bug fixes and enhancements made to PG3x, but since UDI isn't releasing it, it's been just for my personal use.

Yeah, that was the problem with PG3. Sometimes it wouldn't unzip all the files from the package and sometimes it would end up unzipping only part of the file. In your case, it looks like it didn't unzip correctly so the files wasn't complete or was corrupted. I think I might have this fixed but UDI isn't releasing new versions of PG3, only PG3x.

The PG3 log or the node server log? Since the node server isn't starting, there isn't a node server log to display, so that's expected to say not found. If there's no PG3 log, then PG3 isn't running and that's a very different problem When PG3 tries to start the node server, it should report any errors to the PG3 log. So you may want to attempt to start the node server and then switch to the PG3 log (Log menu, not the Log tab on the node server details page), download the log and PM or attach here. I'll take a look.

when the node server queries the Ambient server for data, what it gets back is not valid data. The node server then marks the station as offline until a query responses with valid data.

Testing is going well. Here's a bit of preview: The PG3 log might shed some light on why the node server's not starting. There is a known issue with PG3 where it will occasionally fail to install all of the node server files and that will typically cause the node server to not run. Since no new development (or even bug fixes) are happening to PG3, the current recommendation from UDI is to migrate to PG3x. Having access to your station's data has been a huge help so thanks again for that.

I see in your PG3 log a lot of messages like this: 8/22/2023, 12:26:24 [pg3] error: IoX Response: [MAX TRIES EXCEEDED] [00:0d:b9:53:2a:30] :: [null] :: 5009.897306ms - http://127.0.0.1:8080/rest/ns/profile/12/upload/nls/en_us.txt 8/22/2023, 12:26:24 [pg3] error: Error: POST http://127.0.0.1:8080/rest/ns/profile/12/upload/nls/en_us.txt Failed :: null 8/22/2023, 12:26:24 [pg3] info: ProfileUpload: upload of en_us.txt for slot 12 failed. Mostly, they seem to be related to uploading the profile files and if the profile files for a node server don't get uploaded, the AC may not display any updates from the node server. PG3x makes multiple attempts when it sends anything to the IoX. In general, it should succeed on the first attempt but in your log, the first, sometimes the second and even the third attempt are failing. A few people are also seeing this same thing. I don't know if it's something in PG3x or something in IoX that's causing it, but I'd suggest opening a support ticket.

It looks like a number of the commands had a delay of about 10 seconds. That corresponds with the PG3x send timeout of about 5 seconds meaning that the first two attempts PG3x made to update the IoX status timed out. You can verify this in the PG3x log by looking for lines that start with [Try 2] and [Try 3] If you're seeing those then that's the problem. I'd suggest submitting a ticket as this seems more like a PG3x or IoX problem than a node server problem.

You probably looked at it many times and it looked correct Sometimes it just takes a different set of eyes to see something like that.

geocode sounds like it may be referring to location. Make sure you have a valid location configured.

It re-runs the discovery process which is the same thing it does at startup. The use case would be when you add a new device, run discover instead of restarting the node server.

The '/' in the "Garden / Rec Rm" name is an invalid character for IoX. Thus the IoX never adds the node.