Anyone else having connection issues lately?

[BeanAnimal]

Dave -

I assume you are on a PC?
Can you ping the LAN interface of the P4 with -t
Can you from the same connection ping your local gateway at the same time with -t
Let it go for 1K or so packets. Curious to see if the packet loss is the same or not.

I do not have ANY dropped packets from LAN to P4 in hundreds of thousands of pings. That is why I am so bothered by the speed issues, I know it is not my wifi connection (or my internet connection) and the bottleneck is pretty obviously the ghl cloud.

 

[Lasse]

And does it make sense that my phone can connect to the MyGHL connection, but has very spotty connection to the Profilux over local wifi?

No.

But a question - do you use a VPN for your Internet connection from your device? If I connect some VPN:s to my computer - I can´t connect locally - with some others I can.

Or du you normally have both data transfer over your phone network and WiFi activated the same time? I have been out for my phone have hung up the Data transfer over my phone network and not use WiFi for data transfer when I´m home.. And I´m no able to connect locally to my P4 in these cases. Have to deactivate data transfer over my phone network in these cases

Sincerely Lasse

 

[Dave-T]

Ok, I can ping the P4 (and my router) fine from a laptop. And I can ping the P4 over its own hotspot wifi network with my laptop. No packet loss. It's only with the hotspot from my phone that I see packet loss. And I'm not using a VPN for anything.

If I turn off "Cellular Data" on my phone, I'm still unable to connect directly to the P4 using the GHL Connect app on my phone. The GHL Connect app can only connect using the MyGHL connection. At least right now. This wasn't only the case, in the past connecting to the P4 was hit or miss and I had a better time using the MyGHL connection. But right now, I can't seem to connect at all without using the MyGHL connection.

 

[Lasse]

Dumb question - have you try to restart the P4 - just disconnect it from the grid for 20 - 30 sec and then restart?

Have you access to GHL Control Center? You can do a connection with help of your local IP (TCP/IP) red marking

Does it works? If it works - your problem is probably connected with our your local webserver. You may have to reinstall the whole file system - the thing that I have warned for because you need to make a new network connection with help of hotspot or USB cable. You may need to do a Emergency update (Chapter 3 in the document I attached in post # 15

Sincerely Lasse

 

[BeanAnimal]

I think the white elephant that everyone keeps circling around in all of these threads is that the GHL cloud performance is generally rather slow even on a good day. I think GHL knows it, i think everyone in the room knows it.

We can throw darts at reasons/fixes for local problems but the bigger issue is the overall speed of the service in general.

Some people have local problems (wifi, poor network, phone issues, slow internet) and that just makes matters fuzzier and more frustrating for some, but the underlying slowness is still there.

It may be "fast enough" for some people and other people may be perfectly okay with having to restart the app often or wait for spinning grey boxes, etc.

I would really like to see GHL address this head on and transparently. I love my hardware so far, but really dislike the dashboard (mostly due to speed). I am ok with the rest of the menus/interface.

Hopefully the API gives some relief, where I can build my own dashboard for display (not interaction) and hopefully GHL works to improve the cloud delivery.

 

[BeanAnimal]

Dumb question - have you try to restart the P4 - just disconnect it from the grid for 20 - 30 sec and then restart?

Have you access to GHL Control Center? You can do a connection with help of your local IP (TCP/IP) red marking

Does it works? If it works - your problem is probably connected with our your local webserver. You may have to reinstall the whole file system - the thing that I have warned for because you need to make a new network connection with help of hotspot or USB cable. You may need to do a Emergency update (Chapter 3 in the document I attached in post # 15

Sincerely Lasse

I have found that tcp/ip connection to P4 from GCC is sometimes not possible.

In short - I think the P4 sometimes get stuck (orphaned) connection port (10001) to GCC. Only way to fix it is to reboot the P4. I would think as a fix, a watchdog in code could reset/clear stuck connection/port. Should not have to reboot P4.

It has happened to me several times, but not sure why. I think if i leave GCC connected and computer goes to sleep the connection must break and get stuck on P4.

When this happens tcp/ip to myGHL and browser still work - just port 10001 to GCC is blocked and P4 needs to be rebooted to restore.

 

[Lasse]

I have found that tcp/ip connection to P4 from GCC is sometimes not possible.

In short - I think the P4 sometimes get stuck (orphaned) connection port (10001) to GCC. Only way to fix it is to reboot the P4. I would think as a fix, a watchdog in code could reset/clear stuck connection/port. Should not have to reboot P4.

It has happened to me several times, but not sure why. I think if i leave GCC connected and computer goes to sleep the connection must break and get stuck on P4.

When this happens tcp/ip to myGHL and browser still work - just port 10001 to GCC is blocked and P4 needs to be rebooted to restore.

In the past - at least 2 years ago - and not with my home set up - I have had the total opposite behaviour - the internal web browser get stuck and a reboot was necessary - the client - server works well. This was in a very "noisy" electrical environment. Once - many years ago - I had problems with the client - server program - since when I have always raised the maximum wait time a lot

Another odd behaviour of the GCC in the past have been that if you change anything in TCP/IP related connection settings - you need to close the program and reopen it again befor you use that connection in GCC. I - by mine backbone - always do that nowadays but - I check now and it seems like that bug is fixed for now.

Sincerely Lasse

 

[BeanAnimal]

Yes, I noticed the need to reboot GCC when changes are made. It is still a bug

I don't mind that as much as having to reboot the P4 when tcp/ip GCC ---> P4 hangs. But honestly, my concern is overall speed. I can live with GCC issues.

 

[Dave-T]

Ok, rebooting the profilux seems to have fixed my problem. Now I can connect to the Profilux using the app, over my local wifi. But to BeanAnimal's point - this isn't a fix. The problem is that there seems to be a bug. The bug should be fixed so that the local webserver doesn't lock up.

 

[HuneyBear]

It would be nice and likely help if GHL put a server system in the US. Is clients use US server…

 

[Lasse]

It would be nice and likely help if GHL put a server system in the US. Is clients use US server…

If it is the location is the problem - I would suggest they move it to Europe instead

172.67.209.237 Geolocation Lookup and Detailed Q&A

172.67.209.237 is an external IP address, this IP address represents a device on the Internet. We have detected the device connected this IP address is located

en.ipshu.com

Sincerely Lasse

 

[Gaël]

If it is the location is the problem - I would suggest they move it to Europe instead

172.67.209.237 Geolocation Lookup and Detailed Q&A

172.67.209.237 is an external IP address, this IP address represents a device on the Internet. We have detected the device connected this IP address is located

en.ipshu.com

Sincerely Lasse

Sorry @Lasse, it's a little more complicated than that.

You can't determine that by testing myGHL.com because the myGHL.com site is protected and reinforced by what we call a CDN (Cloudflare in this case), so it's hundreds of servers spread around the world.

On the other hand, the myGHL server is hosted on another cloud service (Microsoft Azure in this case) but located in Europe, the operation of communication with users's GHL devices does not allow unfortunately to run through worldwide distributed servers.

Only static content is delivered with CDN.

Gaël

 

[BeanAnimal]

@Gaël
That is pretty much what my issue is. The local connection to P4 and dashbaord and/or cached CDN content is fine (very fast), as is the the actual route metrics to myGHL.com. So the web page loads quickly, most of the content pages and framework (app or web page) loads quickly. The data itself takes a very long time. The distinction being that live data from the P4 is not too bad, but the delivery of cloud content (charts?) is terrible depending on the time of day. So charts and dosing pumps are the major pain points that make the dashboard frustrating.

 

[Gaël]

I used to have connection issues constantly with GHL Connect, either losing my connection entirely, or the dreaded "Please wait" message being displayed for an overlong period. I originally had my router giving the Profilux a fixed IP address, which the Profilux got from its DHCP query. Later, I told the profilux to use this IP address by telling it it had a fixed IP address. This was a big improvement, my connection issues virtually disappeared. Seems like the Profilux doesn't play well with DHCP. Then, just for grins, I installed a dedicated 2.4GHZ access point that's in the same room as the Profilux and is exclusively used by the Profilux. I'm not sure if this helped, my issues primarily seemed to go away when I set up the fixed IP address. But I know it's common advice for connection issues, and maybe the Profilux didn't like the mesh router I use.

So things were hunky-dory for a few weeks until about a week ago, when my connection issues started happening again. I didn't change anything at my end, so I'm wondering if the problem is at GHL's end. Is anyone else having connection issues? Strangely, I have the biggest problem when connecting directly to the profilux from the GHL Connect app, while on my home wifi. The app seems to do better if I have it connect through the myGHL connection. And I have the best success when connecting from a browser through myGHL.

Sorry to react on this part of the initial question only now.
Wouldn't you be a GHLConnect user on iOS?
In fact, in order to solve the display problems caused by the bug introduced by Apple on iOS 16 it was necessary to modify important parts of the application.
GHLConnect like many applications relies on third party bricks/modules/libraries/framework (call it what you want), it's not possible to design everything by yourself, so we had to replace these modules impacted by the IOS16 bug by other modules that are not impacted by the bug.
The problem is that these modules are not perfect and bring other problems, including the following: local websocket connections on port 80 no longer work and so since version 3.22.15 GHLConnect uses port TCP 10001 on iOS ...
(The port specified in the GHLConnect parameters is ignored and the connection is always made on port 10001)
This protocol, which is the one used by GHL Connect Center, is a bit slower than the websocket and above all it is not possible to make simultaneous connections.
Connections via the myGHL websocket still work. That's why you can observe a better functioning via myGHL.

Gaël

 

[BeanAnimal]

Thank you for the explanation @Gaël
Is this part if the issue where I get locked out of tcp/ip GCC connection to P4 sometimes and have to reboot it?

 

[Gaël]

Thank you for the explanation @Gaël
Is this part if the issue where I get locked out of tcp/ip GCC connection to P4 sometimes and have to reboot it?

No, there is no general problem of this kind. On the other hand it is only possible to make one connection simultaneously on port 10001 so if GHLConnect iOS is already connected GCC will not be able to connect to it as well.

Gaël

 

[Dave-T]

Yes, thanks for the explanation Gael! That explains a lot of what I'm seeing. I was one of the (probably many) people who reported that IOS bug. In this case, to me at least, the cure is worth than the disease. I could live with the IOS bug by just using GHL Connect and a browser if I wanted to do something that was affected by the display issue. But the slow and choppy connections are a worse problem. Is the new issue something you guys are working to fix at some point?

 

[Gaël]

Is the new issue something you guys are working to fix at some point?

Of course:

Gaël

 

[Dave-T]

Thanks. I'm not sure what the screenshot means - that's going to be the fix?

 

[Gaël]

Thanks. I'm not sure what the screenshot means - that's going to be the fix?

This means that yes the team is working on it, and that initially if communication via websocket on port 80 is not functional on iOS it will at least be possible with the next version of GHLConnect which will be available in the coming days , to choose the port used for redirection to 10001 (and therefore allow redirection of several devices with same public IP).

Gaël