Closed simonk1969 closed 2 years ago
Yep, my fault. For some reason v0.0.8 got a buggy version of en.json (no idea how it happened), but I've fixed that in v0.0.9. Try to do another update, you might need to force the integration in the HACS panel to locate the v0.0.9 release using the `Update Information" menu
That fixed it thankyou :-)
I never could get my Hot Tub working with this previously trying to get the spa xml file, etc.
Thanks for your great work, really appreciated :-)
Since updating to V0.0.10 today I'm getting similar errors to yesterday :-(
Is the spa integration working as expected? Can you control the device from HA? I see the errors, I have some in my logs too, it’s because the integration sometimes times out, but I think I’ve seen a pattern and can investigate next week.
No, justs shows everything as UNAVAILABLE.
Work great since installing 0.0.9 two days ago until update to 0.0.10 today.
If you need any more info or need me to test something then just let me know :)
Have you restarted HA? Does it do the same each time?
I have restarted HA but still the same, all entities show unavailable. I've also deleted integration and tol Gecko in HACS to redownload 0.0.9 but after restarting HA and adding integration the issue now remains the same. Also deleted integration and Gecko install, reinstalled Gecko(tried both versions) added the integration but same result.
Hmmm. Sorry you're having such a mare with it. I did some changes earlier on today which I'm just about to commit which deals with some issues when there are retries during the class init after the spa has been configured. I originally thought that this might be the cause of your problem, but I'm not sure. Would you mind uploading the full log file rather than just the HA abridged version from above and I can see if it's similar to a problem I experienced earlier but was unable to reproduce (some exception about index out of range in an accessor)?
Also, can you try v0.0.11? Still interested in the log files to see what's behind the ERRORs.
I've just done a reboot and this was the results in the full ha log file:
2022-02-07 19:45:17 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration kia_uvo which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant 2022-02-07 19:45:17 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration nodered which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant 2022-02-07 19:45:17 WARNING (SyncWorker_2) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant 2022-02-07 19:45:17 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration gecko which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant 2022-02-07 19:45:25 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for sonoff_4chpror2 @ 192.168.30.17: Error connecting to ('192.168.30.17', 6053): [Errno 113] Connect call failed ('192.168.30.17', 6053) 2022-02-07 19:45:30 WARNING (MainThread) [homeassistant.config_entries] Config entry 'WLED' for wled integration not ready yet: Invalid response from API: Error occurred while communicating with WLED device at 192.168.30.86; Retrying in background 2022-02-07 19:46:06 ERROR (Thread-5) [root] Uncaught thread exception Traceback (most recent call last): File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner self.run() File "/usr/local/lib/python3.9/threading.py", line 910, in run self._target(*self._args, self._kwargs) File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 310, in _ping_thread_func self.refresh() File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 340, in refresh if not self.is_connected: File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 335, in is_connected raise RuntimeError("Spa took too long to connect ...") RuntimeError: Spa took too long to connect ... 2022-02-07 19:46:06 WARNING (MainThread) [custom_components.gecko] Facade went into error, lets retry 2022-02-07 19:46:18 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: gecko 2022-02-07 19:46:51 ERROR (Thread-8) [root] Uncaught thread exception Traceback (most recent call last): File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner self.run() File "/usr/local/lib/python3.9/threading.py", line 910, in run self._target(*self._args, *self._kwargs) File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 310, in _ping_thread_func self.refresh() File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 340, in refresh if not self.is_connected: File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 335, in is_connected raise RuntimeError("Spa took too long to connect ...") RuntimeError: Spa took too long to connect ... 2022-02-07 19:46:51 WARNING (MainThread) [custom_components.gecko] Facade went into error, lets retry 2022-02-07 19:47:18 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: gecko 2022-02-07 19:47:36 ERROR (Thread-11) [root] Uncaught thread exception Traceback (most recent call last): File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner self.run() File "/usr/local/lib/python3.9/threading.py", line 910, in run self._target(self._args, self._kwargs) File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 310, in _ping_thread_func self.refresh() File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 340, in refresh if not self.is_connected: File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 335, in is_connected raise RuntimeError("Spa took too long to connect ...") RuntimeError: Spa took too long to connect ... 2022-02-07 19:47:36 WARNING (MainThread) [custom_components.gecko] Facade went into error, lets retry 2022-02-07 19:48:18 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: gecko 2022-02-07 19:48:21 ERROR (Thread-14) [root] Uncaught thread exception Traceback (most recent call last): File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner self.run() File "/usr/local/lib/python3.9/threading.py", line 910, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 310, in _ping_thread_func self.refresh() File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 340, in refresh if not self.is_connected: File "/usr/local/lib/python3.9/site-packages/geckolib/spa.py", line 335, in is_connected raise RuntimeError("Spa took too long to connect ...") RuntimeError: Spa took too long to connect ... 2022-02-07 19:48:21 WARNING (MainThread) [custom_components.gecko] Facade went into error, lets retry 2022-02-07 19:48:21 ERROR (MainThread) [custom_components.gecko] Exception during entry setup Traceback (most recent call last): File "/config/custom_components/gecko/init.py", line 68, in async_setup_entry raise Exception("Too many retries") Exception: Too many retries
Unfortunately v0.0.11 has issue for me.
I'm going to restore a backup from before I installed Gecko the other day and try 0.0.11 from there.
Unfortunately didn't resolve it either, now not sure if I've got a problem with the unit or not!
I've rebooted both the hot tub and Gecko receiver, have a blue light on the receiver and can see it has a IP on my UDM Pro.
Any way to find more details on what is going on, what point it's failing?
Time for a full debug in the shell I think.
Open a command prompt and
pip install geckolib
python3
>>> from geckolib import GeckoShell
>>> GeckoShell.run(["logfile client.log", ‘loglevel DEBUG’])
:
:
Then upload the client.log file here. If your tub is not on the same subnet, you need to add , ’discover IP-ADDRESS-OF-TUB’
to the shell run commands.
Thanks. That log file is confusing! The discover broadcast on your LAN is responded to correctly by your spa, but there are no responses coming back from any of the directed packets after that … the handlers basically run out of retries.
What is confusing is that you appeared to have it working in v0.0.9 but not v0.0.10 but those versions had no change to geckolib which is where the protocol is failing!
I presume your iOS/Android in.touch2 app works fine, and if it does, that’s even more confusing.
Unless, you’ve somehow got two gecko clients on the same machine - did you run that shell on your HA box?
if so, you probably need to remove the HA integration and restart HA to ensure it’s not still loaded.
Otherwise 🤔… brain whirr …
Your correct I did run it on my HA box, removed integration and restarted, log file attached.
Android in.touch2 does connect ok.
Ok, wasn't that then. The logs are basically the same. So ...
The app works fine so it's unlikely anything to do with the in.touch2 module The shell doesn't work, nor does HA, but they are on the same box so might be something to do with that or firewall or Unifi routing rules.
Do you have any other wired or wireless devices that could potentially be used to run the shell to see if there is any difference there?
I've created a Ubuntu VM and ran the test again, log file attached client.log .
Same result I'm afraid.
If the VM is on the same box that we've previously been working on I'm not sure that will get around any networking issues with your host which is where I'm currently thinking we need to investigate ...
But if it's on a different box we need to understand why broadcast UDP from the box gets to the in.touch2 module and back to the host but point-to-point UDP packets aren't.
It's almost as if sending from the host to the in.touch2 module is being blocked somewhere but the broadcast (and the response back) is getting through fine.
I wonder, do you have multiple subnets on your network and if somehow the UDP broadcast is making it through and the packet from the in.touch2 module to your box, but the directed ones from the box to the in.touch2 module aren't
Can you PING the device from the VM and get a response back?
Yes the VM is on the same Proxmox box, which HA is also on. I'll try a setup a Ubuntu physical box a bit later and see if I get the same results.
I'll try and do a bit more research about my UDM Pro with regards to UDP and specifically point to point UDP packets.
I do have multiple subnets VLANs set up all of the devices I'm trying this with are on my main subnet 192.168.1.x.
I can ping the InTouch2 and get a response.
Something else quick to check, if you start the shell and try to get it to connect directly to your spa what happens?
>>> GeckoShell.run(["logfile client.log", ‘loglevel DEBUG’, 'discover 192.168.1.75'])
This won't do any broadcasting but will try to connect direct to the spa.
Looks to be the same.
Should have a physical Ubuntu box ready shortly to try.
From: gazoodle @.> Sent: 08 February 2022 14:26 To: gazoodle/geckolib @.> Cc: simonk1969 @.>; State change @.> Subject: Re: [gazoodle/geckolib] Installing Gecko V0.0.8 on fresh HA install (Issue #27)
Something else quick to check, if you start the shell and try to get it to connect directly to your spa what happens.
GeckoShell.run(["logfile client.log", ‘loglevel DEBUG’, 'discover 192.168.1.75'])
This won't do any broadcasting but will try to connect direct to the spa.
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1032666782 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNQOHOQW4PCV3RJI6KLU2ERYJANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you modified the open/close state. https://github.com/notifications/beacon/AF5ZPNXGYE3IJMTWH6HIAKTU2ERYJA5CNFSM5NS6IGJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHWGT5HQ.gif Message ID: @. @.> >
That is very strange. Is the log file exactly the same? I wouldn't have expected the HELLO broadcast discover to have worked correctly.
The previous times you get
2022-02-08 10:33:44,355 geckolib.locator INFO Discovery process started
2022-02-08 10:33:44,356 geckolib.locator DEBUG Locator retry thread started
2022-02-08 10:33:44,406 geckolib.driver.udp_socket DEBUG Sending b'<HELLO>1</HELLO>' to ('<broadcast>', 10022)
2022-02-08 10:33:45,363 geckolib.driver.udp_socket DEBUG Sending b'<HELLO>1</HELLO>' to ('<broadcast>', 10022)
2022-02-08 10:33:45,375 geckolib.driver.udp_socket DEBUG Received b'<HELLO>SPAd8:80:39:a1:b0:44|Hot Tub</HELLO>' from ('192.168.1.75', 10022)
2022-02-08 10:33:46,382 geckolib.driver.udp_socket DEBUG Sending b'<HELLO>1</HELLO>' to ('<broadcast>', 10022)
2022-02-08 10:33:46,394 geckolib.driver.udp_socket DEBUG Received b'<HELLO>SPAd8:80:39:a1:b0:44|Hot Tub</HELLO>' from ('192.168.1.75', 10022)
2022-02-08 10:33:47,400 geckolib.driver.udp_socket DEBUG Sending b'<HELLO>1</HELLO>' to ('<broadcast>', 10022)
2022-02-08 10:33:47,412 geckolib.driver.udp_socket DEBUG Received b'<HELLO>SPAd8:80:39:a1:b0:44|Hot Tub</HELLO>' from ('192.168.1.75', 10022)
2022-02-08 10:33:48,368 geckolib.locator INFO Found 1 spas ... [Hot Tub(SPAd8:80:39:a1:b0:44)]
I was hoping that there would have been some difference. Sigh.
Well, lets see what your new box shows. Thanks for keeping at this with me.
client.log clientwithIP.log Finally got a standalone box running. Attached is client.log and also clientwithIP.log which is with the IP specific in command line.
Thanks @simonk1969. I'm really not sure what is happening here, but there is a difference we can investigate. The locator class enables socket_opt to support broadcast whereas the spa client doesn't. I have no idea if this will make a difference, but can you edit the file spa.py
, find the function start_connect
and make the following change:
Find the line self.open()
and after it, add self.enable_broadcast()
. Python is fussy with tabs and spaces, so make sure the indent is with spaces.
Should look something like this after ...
def start_connect(self):
""" Connect to the in.touch2 module """
self._connection_started = time.monotonic()
# Identify self to the intouch module
self.open()
# Add the line below vvv
self.enable_broadcast()
# Add the line above ^^^
self.queue_send(
GeckoHelloProtocolHandler.client(self.descriptor.client_identifier),
self.descriptor.destination,
)
:
:
(Truncated)
Then try starting the client again.
This may be a stupid question but where do I find spa.py I’m looking in config/custom_components/gecko and config/ but cannot find it?
I’m using File Editor from within HA.
I have a put a post on Facebook Ubiquiti group for advice as to what could be blocking the UDP packets?
From: gazoodle @.> Sent: 08 February 2022 16:20 To: gazoodle/geckolib @.> Cc: simonk1969 @.>; Mention @.> Subject: Re: [gazoodle/geckolib] Installing Gecko V0.0.8 on fresh HA install (Issue #27)
Thanks @simonk1969 https://github.com/simonk1969 . I'm really not sure what is happening here, but there is a difference we can investigate. The locator class enables socket_opt to support broadcast whereas the spa client doesn't. I have no idea if this will make a difference, but can you edit the file spa.py, find the function start_connect and make the following change:
Find the line self.open() and after it, add self.enable_broadcast(). Python is fussy with tabs and spaces, so make sure in indent is with spaces.
Should look something like this after ...
def start_connect(self): """ Connect to the in.touch2 module """ self._connection_started = time.monotonic()
self.open()
# Add the line below vvv
self.enable_broadcast()
# Add the line above ^^^
self.queue_send(
GeckoHelloProtocolHandler.client(self.descriptor.client_identifier),
self.descriptor.destination,
)
: : (Truncated)
Then try starting the client again.
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1032803147 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNV5YNU2G3EPBCOGAXDU2E7DBANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AF5ZPNUX6K4S3D5XXFKJJITU2E7DBA5CNFSM5NS6IGJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHWHVGSY.gif Message ID: @. @.> >
Ahh sorry, no it’ll be in the package folder wherever your python install put it. The one that HA downloads we need to leave alone.
I think pip show geckolib
should help
Find the line self.open() and after it, add self.enable_broadcast(). Python is fussy with tabs and spaces, so make sure in indent is with spaces.
I tried this earlier but lookslike same results.
I also setup the linux box and intouch2 totally seperate using a old router and it appears to be the same, it broadcasts gets a response starts trying to comunicate directly between the two but gets no responses and times out, so this rules out my network.
I've also reset the intouch2 receiver and repaired, powered off the hot tub for 5 minutes to reboot the transmitter and started it up again.
The android app is still working.
This is just so weird, would say its the receiver if it wasn't for the Android app still working!
?????
Ok, time to get busy :rolls sleeves up: diag script methinks.
Also just to make sure, can you dig out the intouch2 module versions. Should be in the app, related to your tub, I’m not sure precisely as I have iOS version.
Should look like
intouch version EN 70 v14.0 intouch version CO 69 v11.0
From: gazoodle @.> Sent: 09 February 2022 07:12 To: gazoodle/geckolib @.> Cc: simonk1969 @.>; Mention @.> Subject: Re: [gazoodle/geckolib] Installing Gecko V0.0.8 on fresh HA install (Issue #27)
?????
Ok, time to get busy :rolls sleeves up: diag script methinks.
Also just to make sure, can you dig out the intouch2 module versions. Should be in the app, related to your tub, I’m not sure precisely as I have iOS version.
Should look like
intouch version EN 70 v14.0 intouch version CO 69 v11.0
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1033419866 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNSWVNILNEOUNBFIWXLU2IHS3ANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AF5ZPNWBPTPLTG57C3YTYL3U2IHS3A5CNFSM5NS6IGJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHWMLYWQ.gif Message ID: @. @.> >
Another thought occurs, maybe the in.touch module has blocked the app UUID for some reason … don’t see why, but you could also tweak that in driver/shell.py
Change the UUID, generate a new one at https://www.uuidgenerator.net/
SHELL_UUID = "02ac6d28-42d0-41e3-ad22-274d0aa491da"
Or we’re assuming the android app is communicating locally, but if it’s remote then that would invalidate our assumptions.
If you’ve got PiHole or some other way to block a DNS lookup, block intouch.geckoal.com
which will force your app to try locally, then we can confirm that the LAN protocol works.
This is essentially what I had to do while sniffing the conversation early on when building this library.
Another thought occurs, maybe the in.touch module has blocked the app UUID for some reason … don’t see why, but you could also tweak that in driver/shell.py
Change the UUID, generate a new one at https://www.uuidgenerator.net/
SHELL_UUID = "02ac6d28-42d0-41e3-ad22-274d0aa491da"
I'm not a linux expert, quite new to it so hopfully Im in the correct place but I cannot find shell.py
Or we’re assuming the android app is communicating locally, but if it’s remote then that would invalidate our assumptions.
If you’ve got PiHole or some other way to block a DNS lookup, block
intouch.geckoal.com
which will force your app to try locally, then we can confirm that the LAN protocol works.This is essentially what I had to do while sniffing the conversation early on when building this library. I've added intouch.geckoal.com to the block addresses in AdGaurd, disabled mobile data on phone and checked that phone is getting DNS from ADGaurd. The phone app still connects to the hot tub.
Sorry, that path is utils/driver/shell.py
Ok, I've put a simple diag program to help us try to get to the bottom of this. It needs a slightly different install in that you need to get this repo down onto your system. For simplicity's sake, create a folder for source code in your home dir and then clone the repo there.
gazoodle@ubuntudev:~$ mkdir Source
gazoodle@ubuntudev:~$ cd Source
gazoodle@ubuntudev:~/Source$ git clone http://github.com/gazoodle/geckolib
Cloning into 'geckolib'...
warning: redirecting to https://github.com/gazoodle/geckolib/
remote: Enumerating objects: 1218, done.
remote: Counting objects: 100% (1218/1218), done.
remote: Compressing objects: 100% (533/533), done.
remote: Total 1218 (delta 823), reused 951 (delta 596), pack-reused 0
Receiving objects: 100% (1218/1218), 820.79 KiB | 508.00 KiB/s, done.
Resolving deltas: 100% (823/823), done.
gazoodle@ubuntudev:~/Source$ cd geckolib/tests
gazoodle@ubuntudev:~/Source/geckolib/tests$ python3 diags.py
:
:
:
The diag tool does essentially what the shell does, but it's got a bit more debugging and we can fiddle around with it without breaking the library
You might need to install git too
$ sudo apt-get install git
Been a really busy day and looking like another one tomorrow, I'll try and continue with this tomorrow evening.
I really appreciate all the effort you are putting in with me to try and get it working for me :-)
You’re welcome. No hurry.
Rssults below shows unable to get ping results. I've checked on the temporary router that I'm using this ping isn't being blocked and I can't see that it is and also I can actually ping the in.touch2 and get a response, not sure if this is what your diag program is trying to do?
@.***:~/Source/geckolib/tests$ python3 diag.py
2022-02-11 11:36:29,388> INFO Start comms diag
2022-02-11 11:36:29,388> INFO Discovery process started, create socket
2022-02-11 11:36:29,388> DEBUG UDP Socket created, open it
2022-02-11 11:36:29,389> DEBUG Socket opened, set broadcast
2022-02-11 11:36:29,390> DEBUG Broadcast enabled, add hello handler
2022-02-11 11:36:29,390> DEBUG Hello handler added, queue a broadcast
2022-02-11 11:36:29,440> DEBUG Sending b'
receive_handlers=[GeckoHelloProtocolHandler(send_bytes=b'
On Wed, 9 Feb 2022 at 23:05, gazoodle @.***> wrote:
You’re welcome. No hurry.
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1034291794, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNV677SFL7N3IB6KCP3U2LXLZANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
-- Regards Simon King
I'm wondering if there is a fault with the intouch2 so have ordered another should be here on monday. We can prove then for sure if its the unit or not. If it's not the unit then I can see about returning it or just sell it on.
This is very strange indeed. The diag.py program deliberately uses the same socket (which is still in broadcast mode). I assigned a new GUID so your in.touch2 module would never have heard of us before, plus it happily replied to the broadcast HELLO message but then failed to reply to a direct message ????
Also, earlier in this thread, you indicated that it was all working fine so I'm wondering what had changed since then? Maybe your in.touch2 module is playing up, but it's such an odd issue, why reply to the HELLO but not the PING!!!
So, lets think about this. There are the following devices in this setup
We've tried changing the PC (by creating a new Ubuntu box instead of the HA box) We've tried changing the router (by you putting in an old one instead of your UDM) We've tried rebooting all the Gecko stuff (and you're going to try a different in.touch2, thanks that's very helpful) We've not tried faffing with the switch (unless your simple setup was to plug the in.touch2 module direct into the router in which case nothing to see here).
The only other thing I can suggest is a wireshark session. This can be pretty hairy to setup but is the way that I did my original sniffing of packets to see what was going on.
Also, it might be useful if you can describe in detail how all the pieces above are wired up or connected to see where we might put the wireshark probe if we decide to go down that route/
When I was doing my investigation, I had a python session running on my laptop in wifi mode so I could capture packets from both the laptop and the phone to compare - they were using the same AP.
If you use Unifi kit everywhere and have one of their APs, then this can be quite easy to capture the packets, I'll see if I can find the procedure which I put somewhere around here ... :-)
Meanwhile, as I've been typing this I thought of some other things we can try first, so I'll make some changes to diag.py and push them.
Ok, I've pushed some changes to the repo.
You can update your local copy by running the following command in the geckolib folder
git pull
Then you can try the diags again (I've increased the socket timeout to see if that helps) if that doesn't work then
python3 diag.py 192.168.0.100
Which will run the diags without a broadcast, but a direct connection to in.touch2 module
I've tried the above but still ends up with the same response.
I am doing all this testing on the Ubuntu box I made, connected to a ZyXell Router that I found stashed in the loft, factory reset. intouch2 is also connect to this router. I can see in the router clients list that both have obtained a IP. So it's just the three devices isolated from everything else, no internet.
Rather than wasting your time maybe we just wait until I get the other unit on monday and see if I get the same results with that?
Sounds like a plan, but before we do that, can you try this version? I was thinking about why it might not respond to us and one reason might be that it hasn't heard the registration hello message, so this diag.py shoves 5 of them at it just to make sure ... who knows.
So, same pattern, git pull
followed by run the diags. If possible, can you put the output in reply just so I can see if there is any slight change in behaviour?
Thanks
Actually I'm not sure that will work either, I just changed the UUID in my diag.py and removed the HELLO handshake that I assumed was for making the module recognize a client, but the behaviour that you're getting seems like perhaps there is more to this than we think, maybe you've got a much newer firmware that has changed the protocol slightly?
Anyway, if this still happens on Monday, I'll need a wireshark capture when your Android app is doing it's handshake so I can see if that's what the problem is.
@.:~/Source/geckolib/tests$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 14:c9:13:fc:3f:81 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.201/24 brd 192.168.1.255 scope global dynamic enp3s0
valid_lft 259196sec preferred_lft 259196sec
inet6 fe80::ad97:b10:36c3:da9/64 scope link noprefixroute
valid_lft forever preferred_lft forever
@.:~/Source/geckolib/tests$ python3 diag.py
2022-02-11 16:40:51,534> INFO Start comms diag with []
2022-02-11 16:40:51,534> INFO Discovery process started, create socket
2022-02-11 16:40:51,535> DEBUG UDP Socket created, open it
2022-02-11 16:40:51,536> DEBUG Socket opened, set broadcast
2022-02-11 16:40:51,536> DEBUG Broadcast enabled, add hello handler
2022-02-11 16:40:51,536> DEBUG Hello handler added, queue a broadcast
2022-02-11 16:40:52,037> DEBUG socket timeout during socket receive
2022-02-11 16:40:52,037> DEBUG Sending b'
receive_handlers=[GeckoHelloProtocolHandler(send_bytes=b'
On Fri, 11 Feb 2022 at 16:14, gazoodle @.***> wrote:
Actually I'm not sure that will work either, I just changed the UUID in my diag.py and removed the HELLO handshake that I assumed was for making the module recognize a client, but the behaviour that you're getting seems like perhaps there is more to this than we think, maybe you've got a much newer firmware that has changed the protocol slightly?
Anyway, if this still happens on Monday, I'll need a wireshark capture when your Android app is doing it's handshake so I can see if that's what the problem is.
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1036376086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNSSOCIY2RQ6KPBE4L3U2UYWJANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
-- Regards Simon King
Received the new in.touch 2 kit this morning and swopped the house part and paired. Ran the diag.py on the test box and instantly finds it and starts receiving lots of data :-) Moved the house part back onto my network, Reinstalled the Gecko integration and all working in HA :-) Replaced the spa part and repaired all still working okay :-)
Looks very much like there is something wrong with the house part of the Gecko kit and we've both been wasting our time trying to fix a hardware issue!
Well that’s good news, thanks for doing that. Glad you’ve got a working system. I wonder if you’d be happy to do a bit more investigation with the “not functioning” unit … because your Android app worked fine, and I’d like to understand why in case this isn’t down to faulty hardware but something I’m not doing quite right that your old unit objected to but the new one doesn’t?
Of course, just let me know what you need me to do.
From: gazoodle @.> Sent: 14 February 2022 12:19 To: gazoodle/geckolib @.> Cc: simonk1969 @.>; Mention @.> Subject: Re: [gazoodle/geckolib] Installing Gecko V0.0.8 on fresh HA install (Issue #27)
Well that’s good news, thanks for doing that. Glad you’ve got a working system. I wonder if you’d be happy to do a bit more investigation with the “not functioning” unit … because your Android app worked fine, and I’d like to understand why in case this isn’t down to faulty hardware but something I’m not doing quite right that your old unit objected to but the new one doesn’t?
— Reply to this email directly, view it on GitHub https://github.com/gazoodle/geckolib/issues/27#issuecomment-1039020836 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AF5ZPNSUDQ2ZA5L3NQH6QJLU3DXLZANCNFSM5NS6IGJA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AF5ZPNQH23ZZZFQL2WDTBT3U3DXLZA5CNFSM5NS6IGJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHXXDGJA.gif Message ID: @. @.> >
I've been following this thread and it's been a great piece of troubleshooting. I'm slightly alarmed though that the expensive blue box could fail in the way that first one did and potentially stop the integration working :(
I've recently done a fresh installation of HA and this evening decided to try and set up the Gecko integration.
I'm installing through HACS, installation completes and then I reboot, when I then go to add integration I get a blank box popup waiting for input with a submit button (see picture), not sure what it is wanting but I tried the IP of Hot Tub, it then comes back with a box that show Hot Tub and a Submit button (see picture), press Submit and its sits there for ages with spinning icon and then after quit a while it comes back and says Created Configuration for Hot Tub (see picture), click Finish. The intergration then shows Failed to set up (see picture). If I click on configure I see a options windows with six tick boxes but no writing (see picture). If I check the logs there are lots of Gecko errors and warnings (see picture).
Any idea as to what is wrong or what I've done wrong?
Thanks Simon
System Health
Home Assistant Community Store
GitHub API | ok -- | -- Github API Calls Remaining | 4846 Installed Version | 1.21.0 Stage | running Available Repositories | 970 Downloaded Repositories | 4Home Assistant Cloud
logged_in | true -- | -- subscription_expiration | 27 February 2022, 00:00 relayer_connected | true remote_enabled | true remote_connected | true alexa_enabled | true google_enabled | true remote_server | eu-west-2-0.ui.nabu.casa can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 7.2 -- | -- update_channel | stable supervisor_version | supervisor-2022.01.1 docker_version | 20.10.9 disk_total | 31.3 GB disk_used | 6.6 GB healthy | true supported | true board | ova supervisor_api | ok version_api | ok installed_addons | SSH & Web Terminal (10.0.2), Home Assistant Google Drive Backup (0.105.2), Node-RED (10.4.0), File editor (5.3.3), ESPHome (2022.1.3)Lovelace
dashboards | 1 -- | -- resources | 0 views | 1 mode | storage