When I start it manually or when the service was active, it takes a few and then it lives, circles green, wind is updating every 3 secs (if there is any …)
and then when the internet is not available … latest update time next to the 2 circles says when last connection was and circles go red after some time.
What more can I say ???
since restarting the script after the upgrade, it is living it’s life …
No, I don’t think there is anything more you can do!
Essentially the problem seems related to the websocket. If the websocket connection is lost, the code is designed to attempt a reconnect every 60 seconds. If this is occurring, then log output will be printed to the screen. Perhaps you could test this for your setup by turning off your Internet, or disconnecting the pi wifi/network cable.
In your case it seems like the websocket connection is failing, but in some way is not fully disconnecting. Hence the code is not triggering a reconnect. I need to try and investigate why this is (although not sure yet how I can recreate it).
maybe my network setup makes it impossible to detect downtime ???
isp router 192.168.2.1 ↔ USG 192.168.1.1 ↔ devices 192.168.1.x
maybe the fact my USG is bridging between 2 subnets ???
That might be it. Is there any way you can connect directly to your ISP router to test?
I think the solution I need to implement is to disconnect and reconnect the websocket manually if the status icons have turned red (i.e. 5 minutes after the latest observation).
not so easy to do as I need to reconfigure some parts …
edit
I’ll do that tomorrow evening, reconfigure the pi to go to the 192.168.2 subnet… time is a bit to short now before the ip change will come.
Will keep you in the loo^
pi moved to the isp box
now not to sure how I’ll now when it updates the ip though … 
I guess you’ll know if the console crashes, or by the timestamp on the websocket log messages as it tries to reconnect?
Also I can look in isp router, there is a little menu with uptime for dsl link and uptime for adsl ip allocation 
now it is just a question of waiting
Guess the answer was quicker then expected
The ISP switched IP like it does on average once every 24 hours, easy to see tonight as … we had to wait the +/- 1 minute to have internet back
console has not lost it’s socket since it waited like we did and resumed once the ISP opened gates again.
2 options :
or being on another subnet makes it happen or somehow my Ubiquiti security gateway doesn’t play nice somehow with IP switches …
that is something I can’t say. 2 black boxes hardly telling how and why it works as it works
More likely your USG is ‘routing’ between the two unless you did something custom in your USG setup. Those devices come up DHCP on the outside (WAN side) and get whatever address the outside provides by default.
There are a bunch of routers between your pi and where the websocket terminates. One more isn’t going to do anything one way or the other. Run ‘traceroute -n’ on your pi to see how many hops the pi is from wherever you’re going to…
Hang about. Why is your LAN address changing?
The USG is a bit more then just a router, it is a security gateway with firewall, anti I don’t know how many things, also a QOS … so many layers in that thing, some you can see, configure … but there are way more things then what you see. Maybe it just doesn’t allow a web socket to wander between ip’s ???
@GaryFunk not my lan, it is the internet we get from ISP, our ‘public’ ip address. They are like DHCP and lease time is randomly around 24 hours. System they use to prevent you from building a net work via the internet … except if you are smart enough to use dyndns systems. But still, our public address changes once a day on average
It should not matter if your WAN address changes. That happens every day to a lot of routers.
should not, I agree but somehow it does … now why ???
Is your LAN address actually changing?
nope, all fixed ip’s coming from the USG and all devices have it also in their settings, have a very small DHCP range for a few minor devices if they ever need to have an ip (visitor)
I think the “just doesn’t allow” is unlikely…
[…disclaimer - 2 year USG user here, 25+ year Linux networking/iptables guy at $work…]
The USG by default is a NAT’ing firewall outbound, doing port address translation of traffic from the LAN onto outside port numbers on its outside WAN-side address. The return traffic is permitted back in because it’s a stateful firewall permitting ESTABLISHED,RELATED replies to go WAN=>LAN and get un-NAT’d, so to speak.
The isp router is also likely another NAT’ing firewall since you have different inside (192.168.x.x) and outside (public) addresses. It also is doing its own port address translation from its inside address:port to its WAN address:port, with the same flow outbound and replies permitted of only the ESTABLISHED,RELATED traffic back from Internet toward your LAN.
No clue how many other similar NAT’ing firewall/routers are in between you and WF, but it doesn’t really matter.
Any app that needs to hold a connection open to an endpoint needs to be able to gracefully detect that its connection is dropped. It could be a readdressing. It could be a power blip or router stupidity someplace in the dozen+ hops between you and them. It could be lots of things. The app opening/using/closing the websocket needs to gracefully deal with the network not being 100% perfect 100% of the time and not sweat the ‘why’ part.
Great! Glad to hear it works as expected when connect directly to the ISP router. I will try and put a workaround in to the code that makes it work if it is behind your USG, but can’t really promise anything.
The websocket functionality comes from the Autobahn Python module. It has been setup in the simplest possible manner following the examples they give on their website for a websocket with reconnection functionality. Unfortunately I know next to nothing about the finer points of how it works, so any more complex fix is unfortunately beyond my skills. Sorry!
@eric, Not sure if you have kept the PyConsole hooked up directly to your ISP router, but if so, have you found it to be more stable over the last week?
It is stil hooked on isp router and it is still running … no problems so far
only part I didn’t see in action is rain since we are having a veryyyy lonnnggg indian summer 
not going to complain tough plants are thirsty