Jump to content

GTench

Members
  • Posts

    263
  • Joined

  • Last visited

Everything posted by GTench

  1. The modem is also the dhcp server and is a router
  2. I don't know if this will help but here are a few more details concerning what I did. I have an incoming fiber connection to a modem. The modem is connected to a unifi switch with an ethernet cable. The modem has its wifi turned off. Wifi is provided through out the house by unifi access points connected to the switch. I never enabled wifi on the eisy. Eisy is connected directly to the unifi switch with an ethernet cable. My testing consisted of unplugging the ethernet cable from the modem to the unifi switch for a couple of minutes then plugging it back in. If the disconnect/reconnect time is say 15 to maybe 30 seconds the node servers do do show fail but I have not timed this. Disconnect/reconnect of a few minutes caused a fail of all node servers I am using the latest releases of PG3x and IOX.
  3. Bob, The node server authors are passing the issue back to PG3x. EnvisaLink-DSC_6-21-2023_10902_PM.zip YoLink_6-21-2023_11016_PM.zip
  4. I did that first. Here is the reply that I got
  5. GTench

    Node Server Fails

    I already did that and this is what the response was
  6. GTench

    Node Server Fails

    Here is the log file. It seems to take an outage of a few minutes to trigger the fail. A short outage of say 15 to 20 seconds appears to be survivable but I did not time it Maybe just some background on this for interest sake... I( have a number of Zwave leak sensors connected to a Zwave shutoff valve but find working with Zwave wireless sensors to be quite frustrating especially trying to get them to reliably report battery level. I set up a number of YoLink leak sensors in place of the Zwave ones. The Yolink sensors are much easier to work with and the always report status, battery level etc. Knowing that they normallyYoLink_6-21-2023_11016_PM.zipYoLink_6-21-2023_11016_PM.zip require internet access to Yolink's cloud servers to report, I decided to direct connect them to a Yolink relay that I could check the status of even if the Yolink cloud was down. I can check the relay status using either an insteon device or a zone in my alarm panel. In order to test if the direct connect to the relay worked, I disconnected the internet in order to simulate the loss of the YoLink cloud server and that when I discovered all of my node servers failed not just YoLink
  7. Here is the log file. It seems to take an outage of a few minutes to trigger the fail. A short outage of say 15 to 20 seconds appears to be survivable but I did not time it EnvisaLink-DSC_6-21-2023_10902_PM.zip
  8. I will try again later and get the log file
  9. GTench

    Node Server Fails

    I disconnected the incoming internet cable from the modem then reconnected it after a minute of 2. I did not disconnect the cable from my eisy. The eisy was still connected to the internal LAN. I can try again later and send you the log file
  10. Maybe a minute or 2. I was doing some testing where I just disconnected the incoming internet from the modem then reconnected it after a minute or 2
  11. I have noticed that if there is a short internet outage, BlueIris disconnects but fails to automatically reconnect when the internet returns
  12. I have noticed that if there is a short internet outage, YoLink disconnects but fails to automatically reconnect when the internet returns
  13. I have noticed that if there is a short internet outage, EnvisaLink-DSC disconnects and fails to automatically reconnect when the internet returns
  14. OK thanks... will do. Yes, Weatherflow is one of the ones that crashed
  15. OK thanks. Just my opinion but I think if a node server needs/uses/relies on an internet connection then it should be able to recover from an internet outage not just crash. I have 5 node servers and they all fail if there is an internet outage. I guess I could check UD Mobile notifications for a failed node server and do a restart but it would be simpler if it was all automatic
  16. Thanks Bob, Since restarting pg3x does seem to solve the problem, is it possible to add an option/feature/flag to restart PG3x in this situation?
  17. I noticed that if I disconnect from the internet for a short time then reconnect that all node servers are in a fail state and I need to restart PGx3. Is this normal or will PGx3 reconnect by itself after some period of time?
  18. I noticed that after I try to do an update and it fails, I see a yolink failed followed by a yolink connected message seconds apart in the UD mobile notifications repeated about once every 3 hours. It is the only node server that I have that has this behavior. If I do a hard boot on eisy I only see one message indicating that yolink has connected but no 3 hour repeats. Not sure if it means anything to you but it does not seem to impact yolink's operation. Thanks. For now, I just deleted and reinstalled the node server and that worked as it always has. A bit of a nuisance but it works. I notice that the yolink nodes are scattered amongst the other nodes in IOX. The other node servers seem to create one parent entry for the node server with all children nodes below it. Any chance this could be done with yolink? Makes collecting things simpler in case of a reinstall. If I have problems in the future with updates I might take your suggestion and create a ticket
  19. Just tried to update to 0.8.99 but no luck. It is stuck on 0.8.90
  20. Not sure if this will help or not but this is how I check for the alarm status (stay armed, away armed, away armed no bypass) 1. Defined one of my unused zones as type 26 (used for automation purposes only and will not trigger an alarm). 2. Defined an unused PGM as type 17 (away armed status) 3. Connect a zone resistor from zone terminal in step 1. to ground. 4. Connect a wire from zone terminal in step 1. to the PGM terminal in step 2. The zone in step 1. will now show as closed when the system is not armed. When the system is armed, PGM shorts to ground thus bypassing the resistor and the zone shows as open. I use this zone's status from the node server to determine the alarm's status. I repeated this process using 2 more pairs of zone/PGM to define zones reporting "stay armed status" and "armed away no bypass" I believe that I tried just using the PGM status values from the node server but for whatever reason it did not work for me but this was over a year ago so am unclear as to why now. Goose66, I also want to say thanks for the node server. It has been working great for me
  21. I tried both the update button on the Yolink node server page and the install button on the node sever store page. Neither results in an update to 0.8.97. This is the first time I tried to do an update under PGx 3.1.27. I did do an update under previous PGx 3.1.25 or possibly 3.1.26 that worked o.k.
  22. I am on PGx 3.1.27 and IOX 5.6.0 and yolink 0.8.90. Tried updating to 0.8.97 using the update button in yolink node server but system stays an 0.8.90. Doing a yolink restart still results in staying on 0.8.90. I think this process worked under the previous PGx version
  23. Yes, it looks to me like the phone app is the main source (and that makes sense to me too) but the name change is just not being picked up by the nodes unless adding a new (or missing) node. Now that I realize how this is working, I don't mind deleting the node and restarting the node server to have the new name picked up; so, don't worry about changing anything for me. Changing names is something that is quite easy to do this way and is something that would only happen very infrequently for me. If I want to use a node name different than in the app, I could just change it in the AC (overriding the PG3) and I have done this with other node servers. In this case though, I want the app name and the AC name to be the same for consistency and since the AC gets its names from the nodes, I wanted the app and node names to match Yolink is working great for me. I really appreciate all the work that you have put into it Gary
  24. Did some more testing. Basically, if the device name is first changed in the cell phone app, the changed name shows up in the configuration parameter list but not in the nodes list after a restart of the node server. However, if I delete the node in the nodes list first and then do a restart of the node server, the changed name shows up in the nodes list when the deleted node is automatically readded. Looks to me like the "nodes" do not see the name change as a "change" but it does seem to recognize a missing node as a change then readds it with the correct name. Not sure if there is a bug here or that's just the way it works but if so it seems inconsistent
  25. Just an update. I changed the name of one of my speaker hubs in the cell phone app as a test. I restarted the Yolink node server and I see that my updated speaker hub name shows up in the configuration parameters list but the old speaker hub name is still in the nodes list. I have not tried a delete and reinstall as that is a bit of work. Just wondering if you think that would work or is there a fix at your end
×
×
  • Create New...