@eric and @padieter, just released a new patch that re-implements the secure websocket and removes all that annoying debug output 
! If you could bump your consoles to the new version using wfpiconsole patch (just in case you have forgotten the command 
) that would be ace. No need to share any terminal output unless you see an error!
2 Likes
Thanks @peter for your work on the wfpiconsole.
I know this has been asked before but couldn’t find the postings about it.
I got another Pi and set it up on a 2nd HDMI input on my TV so I can just switch inputs to see the current conditions. Since this is obviously not a touch screen, is there any way to change the settings?
You can either plug a mouse into the second pi and use that to click on the buttons, or you can edit the .ini file directly. What settings do you want to change? I can help with the edits you’ll need to make to the .ini file
I tried plugging in a mouse but get no pointer. Was just looking to change the layout of the console.
Hmmmmm, I didn’t expect that re. the mouse. Have you adjusted the resolution of the HDMI monitor to run the console full screen? Does it work if you start the console with the mouse already plugged in?
If nothing works, describe the layout of the panels you want to show I can create the .ini file for you.
The Pi is hooked to my 4K tv and it adjusts it’s resolution to the the input. See attachment. I forced the Pi to run 1280 x 720 as running it at higher resolutions caused the numbers to be small. I know the buttons at the bottom are squeezed down a bit that really doesn’t bother me. I am VNCing in to start wfpiconsole. Tried with the mouse plugged in to start and it doesn’t show up.
What I’m looking for is:
Panel 1 = temperature
Panel 2 = Wind
Panel 3 = Barometer
Panel 4 = Lightning
Panel 5 = Rain
Panel 6 = Sun Rise/Set
No secondary panels as I can’t change to them.
Would also like to get rid of the indoot tempurature display.
That looks like a cool setup! So to get the layout you need, use your VNC connection to open the .ini file with:
nano ~/wfpiconsole/wfpiconsole.ini
Under the [Display] section set: IndoorTemp = 0
Under the [PrimaryPanels] section set:
PanelOne = Temperature
PanelTwo = WindSpeed
PanelThree = Barometer
PanelFour = Lightning
PanelFive = Rainfall
PanelSix = SunriseSunset
Then press ctrl-o followed by enter to save the changes. Finally press ctrl-x to exit. Start the console as normal and you should be up and running. I will look into ways as well of getting the mouse to show up if needs be.
1 Like
Thanks, that took care it it!
1 Like
Sorry @peter, my wfpiconsole stopped updating data on the display twice now. I don’t see any errors in the terminal window.
Is it still stopped after 5 minutes idle ? I had this earlier today when my modem changed IP (it does once every 24 hours for me), socket lost it’s connection but within 5 minutes it came back automagically (scripted this way by Peter)
1 Like
@padieter that’s a good question from Eric. It’ll take between 5 and 6 minutes to come back up, but it would be good to know if it does.
Did you see this freezing behaviour when you were running version 2?
I did not see this freezing behavior running version 2, just started once I updated to 3.1. I’m not sure if I can monitor when/if the IP address changes, but I can once is awhile I can check the IP address manually.
OK, that’s good to know. At least we are hunting a bug that I have introduced, rather than something completely unknown. I assume you haven’t made any changes to your Raspberry Pi since updating from V2 to V3? (like installing new software etc.)?
The challenge I have is that I am still not sure whether the freeze ups are due to the websocket no longer streaming data to the console, or whether the websocket continues, but the console stops processing the new observations.
If the websocket connection fails, it is designed to reconnect within at least 6 minutes of it failing. You don’t need to keep an eye on the IP address, just next time the console freezes leave it at least 6 minutes to see if it unfreezes as the websocket reconnects.
I will create another patch tomorrow that puts the debugging code back into the console that prints the time of the last Sky message received. What is going to be key is to compare this time against the time on the console when it has frozen. If the time is very close/the same, then the websocket connection is still open and the issue is with how the console is processing the messages. If the time is very different though, then the issue is likely to be that the websocket has stopped sending messages. Does that make sense?
Thanks for all the help on this issue - I really appreciate the patience trying to get this tracked down.
That is correct, no changes to the Raspberry Pi anytime before V3. Once I have been helping you out with this bug I have enabled/used SSH and VNC to access the raspberry pi.
Once I notice the console freezes I check what the temperature should be by looking at the WF app, and I try to determine about when it has frozen. Lots of times it has been hours before I even notice it has frozen. Once I get your newest patch, I will watch closely when it freezes and then track down the time. Luckily, I’m working from home so I can check it often during breaks.
Not sure if it helps but, running on a pi4 and not freezing, i see these messages.
This is without any of the patches.
2020-04-02 12:05:20-0400 [-] Client connection lost … retrying …
2020-04-02 12:05:20-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-02 12:05:20-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-02 12:06:20-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-07 21:16:40-0400 [-] Client connection lost … retrying …
2020-04-07 21:16:40-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-07 21:16:40-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-07 21:17:40-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-07 21:17:40-0400 [-] Client connection failed … retrying …
2020-04-07 21:17:40-0400 [-] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-07 21:17:40-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-07 21:18:40-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-09 16:26:29-0400 [-] Client connection lost … retrying …
2020-04-09 16:26:29-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-09 16:26:29-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-09 16:27:29-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-10 10:16:30-0400 [-] Client connection lost … retrying …
2020-04-10 10:16:30-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-10 10:16:30-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-10 10:17:30-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-10 10:21:37-0400 [-] Client connection lost … retrying …
2020-04-10 10:21:37-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-10 10:21:37-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-10 10:22:37-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-13 02:56:16-0400 [-] Client connection lost … retrying …
2020-04-13 02:56:16-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-13 02:56:16-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-13 02:57:17-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-13 04:21:34-0400 [-] Client connection lost … retrying …
2020-04-13 04:21:34-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-13 04:21:34-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-13 04:22:34-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-17 17:08:47-0400 [-] Client connection lost … retrying …
2020-04-17 17:08:47-0400 [WeatherFlowClientProtocol (TLSMemoryBIOProtocol),client] <twisted.internet.tcp.Connector instance at 0x6fe66ef0 disconnected IPv4Address(type=‘TCP’, host=‘ws.weatherflow.com’, port=443)> will retry in 60 seconds
2020-04-17 17:08:47-0400 [-] Stopping factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
2020-04-17 17:09:47-0400 [-] Starting factory <main.WeatherFlowClientFactory object at 0x6fe48bb0>
@chuckmc what you are seeing is normal behaviour. Every now and again (April 2nd, April 7th, April 9th, April 10th, April 13th, April 17th), the websocket connection has gone down (for whatever reason), and has then reconnected 60 seconds later as designed.
@padieter I have released a new patch with the debug output added back in to try and diagnose the issue you are seeing. To stop filling the terminal with lots of unnecessary lines like last time, the debug output is now printed to a file called wfpiconsole.log. Can you patch your console with wfpiconsole patch and then start it manually from a terminal with wfpiconsole start. Then using a second terminal in VNC or SSH use the command tail -20 ~/wfpiconsole/wfpiconsole.log to see the last 20 lines of the log file. When you notice that the console has next frozen, can you share with me the time showed by the clock on the console and the last 20 lines of the log file? Also, please don’t stop the console running immediately once you have noticed it has frozen.
@peter my wfpiconsole is updated to 3.1.6 and running smoothly.
@peter, my display froze at about 7:43 am CDT. I grabbed a log but it does not show anything and the log stops at 7:42:26 am as you see. My wfpiconsole stopped after I was monkeying around with grabbing the Log. Does closing a terminal window that i used to start the wfpiconsole stop the application? If so, that is what I did and I will try not to do that again.
April 22 log after 3_1_6 patch.txt (1.1 KB)