Jump to content

bpwwer

Moderators
  • Posts

    3178
  • Joined

  • Last visited

Everything posted by bpwwer

  1. I looked at the files too and noticed that. This doesn't appear to be an internet outage but a local network outage which is a very different thing. There's a lot of local network communication between components and if that is disrupted for more than milliseconds, it may be unrecoverable. The MQTT connection between a node server and PG3x is happening on 127.0.0.1, that's not even external to the machine so for that to get a handshake error implies that something is actually blocking network activity on the local machine. I'll have to do some investigation but even unplugging the network connection should not effect that connection.
  2. When the version reverts like that, it means the node server code is sending that version after it starts. PG3 access the node server store record for the node server and that record has version as 1.1.01 so PG3 assigns that version to it's internal record of the node server. Then with the node server starts it passes version 1.1.0 to PG3 and PG3 updates it's internal record to reflect what is actually running. There were versions of PG3x that had issues with permissions of node server files such that once installed, it wasn't able to update them. I believe that was fixed in 3.1.26 so make sure you are running a recent version. You could try installing in a different slot, doing that would guarantee that you have the most recent node server code installed. If you still see the issue, then the node server package that is out on the server isn't matching the version listed in the node server store.
  3. Yes, I agree, they shouldn't crash. You can help by reporting the issues to the node server authors. And there's a good chance that some of them may be my node servers, I know many/most of mine don't handle lose of network connectivity well and it's on my list of things to fix eventually.
  4. There were a log of things that changed with the eisy release. Probably too many. We're working to make it better and get things to be more stable. Many people have no issues at all and everything seem to work as intended. But for others (as shown by the posts here and other threads) it just doesn't. It seems like a lot of the issues occur during the update process and things are getting updated quite frequently. If nothing happens when clicking the login button for PG3x, it means that UDX is not sending back a response when PG3x tries to authenticate. PG3x is simply waiting for that response that never seems to come. The first thing to try is to simply reboot the box. If a reboot doesn't work, then you may need to run (or re-run) the upgrade process ("Upgrade Packages" from admin console, followed by reboot, followed by a refresh/reload of the PG3x browser page). If that still doesn't work, you'll need to submit a ticket.
  5. @agoltz It sounds like you're using PG3x and not PG3. PG3x depends on IoX and on another UDI component called UDX. It queries UDX to get the IoX credentials for authentication. So if you're having issues accessing IoX, that will also impact your ability to log into PG3x. If nothing happens after clicking the login button, then it probably means that UDX is not responding to the request to authenticate. Sometimes a reboot will correct things. Other times it is because something didn't go right during an upgrade so you need to run "Upgrade Packages" from the Admin Console. Since it sounds like you can't access the Admin Console either, you may need to attempt one of the multi-button press commands to get it to try and upgrade again. There's also a way to ssh into the box and manually start an upgrade.
  6. PG3x doesn't know the internet connection was off-line so it can't detect that situation. It doesn't know why the nodes servers failed, just that they have. The problem is with specific node servers. Some don't handle the internet disconnect well others do.
  7. Oops you must not have the updated firmware. 1.0.3 should handle that correctly now.
  8. You should be able to restart the node servers without having to restart PG3x. However, PG3x won't try to restart them automatically. The "failed" state means that the node server failed and disconnected from PG3x unexpectedly. In your case, the node servers are likely crashing when they get disconnected from the internet. Most are not designed to recover gracefully when that happens. This is something that would have to be fixed in each of node servers.
  9. Sorry about that, I didn't realize that the change I made would also effect the code. It should be fixed now in 1.0.2
  10. @BamBamF16 Have you tried starting the node servers? If they don't start, download the PG3 log package and PM it to me.
  11. I can't do anything about #1, that is a limitation of what the IoX will accept for node names. I can fix #2. I'll change it so that it looks like: This also changes the drop down so that the options are "Set Shade Position" and "Set Shade Speed" instead of both being just "Set Shade".
  12. Run "Upgrade Packages" again. Once it completes, reboot. Once everything is back up, refresh the browser page.
  13. @JKlinefelter That makes sense but I'm not sure how the node server can detect that from the incoming data. The incoming data has field names suffixed with 1, 2, 3, etc. The channel number I guess. So the node server lumps everything with a suffix of '1' under a single node. There's no indication in the data that it may be multiple sensors or a single sensor. The IoX considers it illegal to have two node values of the same type. So what's happening is that when there are 2 sensors with a suffix of '1', they both may be reporting battery status, but since the node can only have one battery status it the node server creates an illegal node definition and the IoX rejects it. Because there can be so many different combinations of stations/sensors and Ambient doesn't send anything but a list of field names/values, the node server has no way to know what sensors/values are going to be reported ahead of time, it has to process that in real-time and dynamically create nodes based on what it sees. I don't really have any ideas for a better way to handle this. It seems like trying to do any type of user configuration would be a real challenge given the limitations of the PG3 configuration screen. The right solution would be for Ambient to re-design their data structure format to provide the info needed actually parse it. I can try and improve the parsing logic in the node server, but it is already quite complex because the field naming conventions aren't all that consistent. Anything I do will end up making assumptions that may or may not hold in the future and may simply result in dropping data if it thinks it will create illegal nodes. Since I don't have any Ambient equipment and I haven't seen it documented anywhere, I had no idea the suffix numbers represented channels.
  14. No difference between Polisy and eisy that I'm aware of. But that's not a PG3 issue as the IoX handles the upgrade process so you might want to ask this on the IoX firmware support thread.
  15. I don't believe so. But you can install the node server in multiple slots with each using a different gateway.
  16. Please submit a ticket. The 403 error is not something I've encountered before and it's not something fixable in PG3, it's the IoX firmware.
  17. Looks like there's an AWS issue effecting many of our AWS based services (portal login, node server store, etc.) No ETA for resolution at this time.
  18. A bug in the UI, reloading the browser page should correct it.
  19. When PG3 tries to add the nodes to IoX, the IoX is responding with forbidden (http error 403). The initial connection to the IoX is succeeding so it's not a problem with configuration and forbidden isn't an authentication error. I don't know why the IoX would return that. Have you exceeded the number of nodes allowed on the IoX? I'm not sure what the limit is, 1000 maybe more.
  20. Eventually, only PG3x will be supported and PG3 will be deprecated. The current state is: * eisy can only run PG3x * Polisy can run either PG3 or PG3x, but once you migrate to PG3x, you can't migrate back. PG3x has remote access capabilities that PG3 doesn't. Currently the Ring node server makes use of this and thus, will only run on PG3x. PG3 is probably a bit more stable and we're working to get PG3x to the same point. My slowly transitioning uses from PG3 to PG3x we have time to stablize PG3x without dealing with a flood of migration issues.
  21. The reboot is supposed to: 1) install PG3x, overwriting PG3. (There is no visual indication this is happening) 2) start PG3x, which detects that it needs to migrate from PG3 and starts migrating node servers - If you connect to PG3x via the WebUI during this process, you'll see pop-up message as each node server is migrated Note, that you do have to close the WebUI to PG3 and open a new browser window for PG3x. Note2, PG3x uses the same login credentials as the Admin Console, it has no default nor does it use whatever you changed PG3 login credentials too.
  22. I'm not familiar with the SolarEdge node server code, but typically, a node server will attempt to create the nodes on the IoX when it starts. First try restarting the node server, it should attempt to add all of it's nodes to the IoX. If it still doesn't work, we'll need log information (download log package from the node server log screen) and post or PM the node server author.
  23. It would be better to move issues with OpenWeatherMap to the node server specific forum. However, if you enable debug level logging, you'll see the actual URL that the node server is using to query data from the servers. You can copy and paste that URL into a browser and see exactly what the server is returning. @apostolakisl if the store isn't displaying you might want to try rebooting then refreshing the browser page. It may be that PG3(x) doesn't have Portal credentials but something is cached and not allowing it to prompt you form them. @kurelgyer If you can't log into PG3x and you don't get an error response when you try, it typically means that a system service on the eisy/polisy is hung and you'll need to reboot to get it working again. In some cases, you may need to run "Upgrade Packages" followed by a reboot.
  24. @Michaelv Looks like the same issue as @mitchmitchell, the plug-in is not able to see or connect to the eisy. Make sure you have the correct ipaddress / port information and the correct username/password.
  25. Hello Everyone, This is the support thread for PG3x v3.1.29
×
×
  • Create New...