[Bug]: BLE device does not work after moving to another gateway #194
Comments
|
The integration does give you the ability to modify the IP however after you change it, it will instantly return to old IP. Why it revert back to old IP? I think the best way to fix this is by while it updating the localkey it updates the gateway id to new one as well. |
Do you need something from my side for that fix? |
* Groups set dp values is now set values together instead of set dp on it's own. * Sub-devices updated localkey also update the node_id and gateway id.
|
I did made changes however I haven't tested this :) let me know if this actually do the job! edit: changes made on master. note: that if sub device infos updated you will need to reload integration manually |
|
I have to wait for a beta or a new release, because HACS always reverts to the top of the list of versions when I try to Redownload, and I'm not experienced enough for manual install for the master. |
|
Released beta2 you can test. |
|
No luck! I've moved the sensor back to the original gateway while it was diabled in LocalTuya. Then I enabled it. Then I updated to beta2 and restarted HA. TRhen I moved the sensor to the other gateway. Reloaded LocalTuya, even restarted HA again, but the sensor again has the new local key, but the old IP address. Just in case, tried Reconfigure to change the IP address to no avail. |
|
Can you download the device diagnostics "after it changed" so in-order to sub_device to change there "ip" the gateway_id in config should also updated with localkey as well. I want to check if it updated or not also an info logs should shows |
|
No, gateway_id is not updated! Only the local_key is changed when I move the device between gateways.
I've enabled logging for LocalTuya and for the sensor, restarted HA, moved the sensor to another gateway. There is no such a record in the home-assistant.log, though the local key has been changed. The only related records are: |
|
This will trigger once after the localkey changed. so if the localkey is the same it won't update other stuff. now inside of device diagnostics file does the gateway updated to the new one or not. |
|
I made a little change you will need to re-download beta2 from HACS. After you re-download revert the sub-device to the old "localkey". well If the localkey change everytime you switch device between gateways it should run normally no. |
I'm not familiar with Python. Found and tried to understand Yes, the cloud_data contains the new local_key, but the "magic" does not happen, and the gateway is not updated.
OK, will do it tomorrow. |
|
Redownloaded beta2, and it does not work. I've inserted debug prints into I've inserted (common.py) It means, your code never calls But the place I've put the call to was wrong: HA became so slow on its start, that it can't even make another graceful restart I initiated after removing that line of code. I had to restart the VM with HA. After such a restart my sensor again had wrong gateway info :( OK, I've removed that bad line, and added it to another place, to be: and voila - after HA restart, the sensor has updated local key and gateway. In some minutes I found and I expect its data updated quite soon! But I'm not quite sure if that call now in a good place for all the cases! It's up to you to decide. |
Yes: HA started to show the data form the sensor! |
|
I believe the best and the only place to call something like |
It because Home Assistant save the states every 15-minutes and when it restarts probably using the service When you mentioned that "only the localkey automatically updated" I just assumed it was called it because I don't know what actually happened does this work good for you it's good place because this only called if the device ID actually doesn't exist anymore any this doesn't happen unless the user somehow added the device with different device ID. except Exception as e:
if not (self._fake_gateway and "Not found" in str(e)):
e = "Sub device is not connected" if self.is_subdevice else e
self.warning(f"Connect to {host} failed: {e}")
await self.abort_connect()
await self.update_local_key() |
|
The change I made almost works. Consider this log: The line 333 (/config/custom_components/localtuya/common.py) in this log is exactly the line I've added to call Note, that all other calls to
I have no idea why |
|
How much time it takes for the sub-device to move from GW 1 to GW 2, and how much time it takes LocalTuya will update them? edit: Does the Node ID changes when the GW changes as well? |
|
I'll do more tests later today. Meanwhile, "move from GW 1 to GW 2" is a two steps action in Smart Life:
Both steps are peformed via Internet connecton to the cloud, no direct BLE connection from the app to the device is required. The time between these actions is undefined. I'll check statuses and the log in between, and after step 2, and will report you. |
|
I believe the current state of this part of the code is good to release.
I think you should keep it while the device_id is still in the list of devices from the cloud. I've made the following tests: Test 1
Test 2
So,
When a device is detached from its GW, its local key is changed to a very different value (no a gateway has such a local key), and node id becomes null. When the device is attached to a new gateway, its local key is changed to the gateway's local key, and its node it is restored to the previous value (at least what I see). So, if LocalTuya parses the device list every time it is updated from the cloud, it may find out that node id became null, but it is unlikely, if the user attached the device to the new gateway fast enough. It may check for local key change and force disconnect from this device, to hope that the following connect attempt would find the device on another gateway, but I think it's a waste of efforts. Right now I think it is good enough to request a user to reload TuyaLocal after moving a device to another gateway. I attach a set of diagnostics files:
Please note, that detached device is the case when |
|
There's an issue I have noticed before I didn't fixed it yet, so the device is actually moved to new GW and localkey probably updated the information of the sub-device, it seems the entities goes shutdown this is probably due to delay on shutdown entities I made before. So what I can think of is that when you reload localtuya you actually enabling the entities not actually re-link the device to the new GW
This should be handled after the refactor commit. edit: Another thing I just found is that update_localkey won't works if the sub device isn't the fake gateway, and I'm not sure if there's a scenarios can lead to this point. not even sure if this may cause an issue in you cases as well. |
* Sub-device now will check the localkey of the gateway if it doesn't match it will raise an expectation.
|
@Lurker00 Do you have a gateway with protocol version: |
|
No, all my 3 gateways use protocol 3.4. But I have two WiFi devices with 3.3: a fan and a plug with power monitor, and I experienced no problems with them. |
|
Is the past a few days I was testing a command and use it as a heartbeat for sub-devices this will let us know if the sub-device disconnected from the gateway and update the sub-device information without need to reload Can you test it with your sub-device that change the gateway then see if it will re-connect to it. |
|
Yes, I can. Will you prepare beta7 for that with all the changes made since beta6? |
Released beta7 |
|
First of all, there are new, misleading, messages: Why LocalTuya even tries to use a BLE device "as a gateway"? Then. I've moved "К: T&H Сенсор" to another gateway. It was detected almost instantly: and then it works and updates its measurements. But... (later) |
|
... an old problem happened that I can't investigate to report: sometimes LocalTuya dispatch messages to a wrong device. You saw it in my logs before, now this is another example (messages from a scene switch and a bulb go to the T&H sensor): It happened many times. Full log attached. But it is not related to the main test. |
It doesn't exactly uses the BLE device as gateway, it uses the BLE Device instance as gateway and it's completely fine since any sub-device as long it's connect to the gateway IP it can be used as gateway, as for why it uses BLE device instance it probably because it's the first sub-device you added into localtuya.
means?
Can you post the "entity diagnostics", I want to also see the other devices configs that sending related to this one :) |
Means, the changes to detect a device detached from one gateway and attached to another gateway seems to work as expected.
Here my whole devices list: It seems when LocalTuya is waiting for a particular |
|
I know that there is an issue on waiting edit: I'll dig more into this. |
|
Just to ensure that nothing goes wrong in From this
hass-localtuya/custom_components/localtuya/core/pytuya/__init__.py Lines 839 to 858 in 5d8dced To this
if "dps" not in decoded_message:
return
self.dps_cache.setdefault("parent", {})
if dps_payload := decoded_message.get("dps"):
if cid := decoded_message.get("cid"):
self.dps_cache.setdefault(cid, {})
self.dps_cache[cid].update(dps_payload)
else:
self.dps_cache["parent"].update(dps_payload)
listener = self.listener and self.listener()
if listener is not None:
if cid and cid in listener._sub_devices:
listener = listener._sub_devices.get(cid, listener)
device_status = self.dps_cache.get(cid, {})
else:
device_status = self.dps_cache.get("parent", {})
listener.status_updated(device_status)To ensure that it only updates that sub-device that added on HA only. |
|
Done. After restart I still see exceptions due to wrong dispatch. I attach the full log. I also forced logging of deciphered data for better understanding who is the real source of the messages. I still believe that |
|
I think this should fix the issue. In line From this
hass-localtuya/custom_components/localtuya/core/pytuya/__init__.py Lines 1058 to 1068 in 5d8dced To this
async def status(self, cid=None):
"""Return device status."""
status: dict = await self.exchange(command=DP_QUERY, nodeID=cid, delay=False)
self.dps_cache.setdefault("parent", {})
if status and "dps" in status:
if "cid" in status:
self.dps_cache.update({status["cid"]: status["dps"]})
else:
self.dps_cache["parent"].update(status["dps"])
return self.dps_cache.get(cid, {}) if cid else self.dps_cache.get("parent", {}) |
The restart with this change was without exceptions. Let's see how it will be running. Then I moved BLE "К: T&H Сенсор" to another gateway, and it was detected on the new place quickly, without exceptions. |
xZetsubou
added
the
master/next-release
github-actions
bot
added
stale
and removed
master/next-release
LocalTuya Version
3.2.5.2b1
Home Assistant Version
2024.4.1
Environment
What happened?
Unlike Zigbee devices, a BLE device can be detached from a gateway and then attached to another gateway, keeping the same device id. I have two BLE capable gateways. When I moved a BLE sensor to another gateway, LocalTuya automaticaly updated its Local Key, but not the IP address of the new gateway. If I try to "Rreconfigure existing device", it allows me to change the IP address, but does not save and does not use it. If I move the device back, it updates the Local Key and the device becomes accessible.
The current (old gateway) IP address is 192.168.0.33. The correct (new gateway) is 192.168.0.32.
If it is not possible to detect the new IP address automatically (at least it can be guessed from the Local Key and the list of gateways), please allow to manually edit it.
The device is battery powered T&H sensor with LCD display, if it matters.
Steps to reproduce.
Add a BLE device to a gateway, then detach it and attach to another gateway. Then the connection is lost.
Relevant log output
No response
Diagnostics information.
localtuya-944c1616039a1d1ec6b9745179bff74e-ВС_ Градусник-61d84145af21bdd68c392c89a0e8c43d (1).json
The text was updated successfully, but these errors were encountered: