Hello,
I purchased 2 (one for a spare) WiFi Relay Controller with High Power Relays with WiFi communication and am having a problem with both of them.
The controller is mounted in a plastic box with two 2.5" vents and a fan under my porch and I’m communicating with it via Visual basic using the NCD .dll.
I have a strong WiFi signal on the porch. The access point is on the other side of the wall.
Everything works fine, but every day (seems like only during the day), the controller becomes unresponsive both to my VB program as well as the NCD Base.
I have to power it down and back up to get it to communicate again.
The controller box is sheltered from direct sunlight as well and doesn’t seem to be more than slightly warm. The only other things in the box is a current transducer and a small DIN mount 12vdc supply.
I’ve tried changing the UART Delay between TX Bytes and the UART RX timeout but doesn’t seem to matter where I set them.
Any ideas?
Mark
Hi Mark,
Can you answer the following:
- What are you controlling with the relays.
- Is the relay controller’s power supply source being shared with any other loads?
- Is the WiFi module Red or Black/silver?
- How long have you had the controller and did this issue just recently start occurring or is this a new installation?
-
I’m off grid (solar) and bought a new RAV4 Prime PHEV, so I’m controlling the charging 120vac outlet for the car. Basically when my main home battery bank is charged, it diverts power to the car.
-
No, the power supply is only powering the controller. It’s a 12vdc 3.33 amp DIN mounted supply.
3.The WiFi module PC card is blue, and the can on top is silver.
- This is a new installation.
Hi Mark,
I’m going to assume your software is establishing a TCP client socket connection to the board and commands are being passed to the controller via that connection. Let me know if this is not true.
One important thing to keep in mind is that the controller only accepts 1 TCP client socket connection at a time. If for some reason the TCP socket connection is not properly closed then the controller will have no way of knowing that the socket was closed and will assume a socket is still open to it. The next time the controller “freezes up” look at the LED on the board. Is it solid green? If so this means the module believes a TCP client is connected. This will let you know if the socket not being properly closed lead to the “freeze”. Let me know what the LED is doing when the controller “freezes”.
Thanks Travis,
I think that the reason this was difficult to troubleshoot was the classic case of having two issues instead of one.
First, I think my WiFi access point was getting flakey and sometimes dropping the connection. I replaced the access point this morning.
Secondly, I guess I expected the TCP socket to close upon loss of WiFi connection. So, I had my software try to reconnect upon loss of communication with controller but as you said, the TCP socket needs to be closed properly so I added “NcdComponent1.ClosePort()” before attempting to re-open it.
Seems to be working this morning. I’ll know soon enough if the problem is resolved.
Thanks,
Mark
Hi Mark,
Another thing I would recommend in your application is to always open a connection, send command, then immediately close the connection. That will significantly reduce the possibilities for a broken socket.
I considered that, but opening a connection is very slow, several seconds. Is this normal?
Still having the problem. Power cycling the router re-enables the connection.
That would be strange that power cycling the router would re-enable the connection. Can you view connection strength information about client devices on the router? Wondering if it has poor wifi signal strength.
It’s got a -58 dBm at the access point for the controller.
That’s a really good connection so I would say that isn’t the problem.
Are you assigning a static IP to the controller that is outside the DHCP address range of the network? If not you might try that just to make sure there isn’t some sort of IP address Conflict issue. Alternatively you could do an IP reservation on the network router for the board’s MAC address, in many ways that is even more reliable.
Yes, it has a static IP on a subnet. Nothing else has its address.
I added the controller code to a SCADA program I wrote that monitors and controls my utilities and runs once a second.
Since it takes a relatively long time to open and close the controller “port”, I’ve changed the code so that the controller code runs in it’s own thread with opening the port before each command and closing it afterwards.
It’s a mystery to me, but I’ll see if this works and I can live with the slower response.
Let me know what you find. I have not encountered this issue with any other customers in the past but we could try adding an inactivity timeout to the firmware if need be.
So far opening and closing for every command while running in its own thread is working, but I’ll let you know. An inactivity timer would be a plus.
1 Like
Still have the same problem. Controller becomes non-responsive and can’t connect to it even with closing the port after every command.
Hi Mark,
Would you be willing to send over the snippet of the program that is communicating with the board if possible? I’d like to take a look to see if I can find anything there. We’ve sold a lot of these modules and I haven’t had a report of something like this so I’m wondering if there is an issue somewhere else.
Sure, other than a manual control of the relay dialog, this is the whole sub routine.
Private Sub PHEVcarCharger()
'************************************** PHEV Car Charger *****************************************
'Had problems with controller becoming unresponsive when leaving the NcdComponent port open, so
'even though it slows down the communication to the controller, I'm open the port for each command and closing it afterwards.
Try
NcdComponent1.OpenPort()
If NcdComponent1.IsOpen = True Then
NCDnotFound = False
Else
NCDnotFound = True
Label17Visable = False
Label18Visable = False
Label16ForeColor = Color.Red
Label16Text = "Time out"
End If
Catch
End Try
Dim CarChrgRelayStatus As Byte
Try
If NCDnotFound = False Then
If NcdComponent1.IsOpen = True Then
'display SUV picture and status text when charging
CarChrgRelayStatus = NcdComponent1.ProXR.RelayBanks.GetStatusInBank(0, 1)
NcdComponent1.ClosePort()
'Divert power to PHEV by turning on WiFi NCD relay when SOC >= 99.8%
'Limit on time to 6 hours in case of this program is closed or communication is lost
If ((BatterySOC >= 99.8) And (CarChrgRelayStatus = 0)) Then
Button5BackColor = Color.LightGray
Button5ForeColor = Color.Black
Button5Text = "Manual Control Off"
'NcdComponent1.ProXR.RelayBanks.TurnOnRelayInBank(0, 1)
NcdComponent1.OpenPort()
NcdComponent1.ProXR.Timers.SetDurationTimerImmediately(1, 6, 0, 0, 0)
NcdComponent1.ClosePort()
End If
'Turn off power to PHEV by turning off WiFi NCD relay if SOC <= 99.4%
If ((BatterySOC <= 99.4) And (CarChrgRelayStatus = 1) And (Dialog14.CarChargeManualOn = False)) Then
Dialog14.CarChargeManualOn = False
NcdComponent1.OpenPort()
NcdComponent1.ProXR.RelayBanks.TurnOffRelayInBank(0, 1)
NcdComponent1.ClosePort()
End If
'Read NCD WiFi relay analog in 0 (AC current)
NcdComponent1.OpenPort()
AinOne = NcdComponent1.ProXR.AD8.Read10BitsValue(0)
NcdComponent1.ClosePort()
'Scale to equal 20 (amps) full scale
AinOneDec = (AinOne * 1) '1.166666666666667)
Label17Text = CStr(AinOneDec)
If CarChrgRelayStatus = 1 Then
If AinOneDec > 2.0 Then
Label16ForeColor = Color.Blue
Label16Text = "Charging >>>> "
Label16Visable = True
Label17Visable = True
Label18Visable = True
Else
If AinOneDec > 1.0 Then
Label16ForeColor = Color.DarkGreen
Label16Text = " Full Charge"
Label16Visable = True
Label17Visable = False
Label18Visable = False
Else
Label16ForeColor = Color.Black
Label16Text = " Unplugged"
Label16Visable = True
Label17Visable = False
Label18Visable = False
If Dialog14.CarChargeManualOn = True Then
Button5ForeColor = Color.White
Button5BackColor = Color.Blue
Else
Button5ForeColor = Color.Black
Button5BackColor = Color.LightGray
End If
End If
End If
Else
Label16Visable = True
Label17Visable = False
Label18Visable = False
Label16ForeColor = Color.Red
Label16Text = " Charge Off"
Button5Text = "Manual Control Off"
Button5ForeColor = Color.Black
Button5BackColor = Color.LightGray
Dialog14.CarChargeManualOn = False
End If
End If
End If
Catch
'If connection to NCD relay controller is lost while running, display "Disconnected"
Label17Visable = False
Label18Visable = False
Label16ForeColor = Color.Red
Label16Text = "Time Out"
Label16Visable = True
End Try
End Sub
I believe I might have discovered what was causing this weird behavior.
If there is no problem for the next couple of days, I’ll let you know.
1 Like
Discovered that the problem (controller becoming unresponsive) was due to the WiFi access point not receiving an acknowledgement from the controller in a timely manner when the WPA2-PSK encryption password was changed by the WiFi access point every 3600 seconds.
This stopped the access point from communicating with the controller, but as far as the controller was concerned, it’s TCP port was still open. Hence either the controller or access point needed power cycled to regain communication.
I changed the WiFi access point “Group Key Update Timeout” as well as the “Pairwise Key Update Timeout” from 1 second to 10 and the problem disappeared.
Thanks for the help in narrowing it down to something on my side. Good to have it working after going down a bunch of rabbit holes. And yes, a timeout port close in the controller firmware would be useful.
Thanks again,
Mark
Hi Mark,
Great. Glad you got it working. I will add an inactivity socket timeout to the roadmap for the next firmware update.
Thank you and have a great weekend,
Travis
Spoke too soon. It did run longer than it ever had, but did fail an hour ago.
As you noted, it’s odd that power cycling the access point restored communication along with having replaced the access point with a new one seems to point to something to do with the WiFi as the problem.
I’ve now disabled the Group Key Update Interval temporarily to see what effect that has.
Question, does the WiFi module have the processing power to do AES encryption?