How to: changing from /dev/ttyACM0 to /dev/USB0?

version: core-2022.2.6
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
user: root
virtualenv: false
python_version: 3.9.7
os_name: Linux
os_version: 5.10.92-v8
arch: aarch64

So here’s the thing. I have my Zigbee coordinator setup on /dev/tty/ACM0. A about a year ago as HA newbie I plugged in this cc2531 module and started adding zigbee sensors.

Now that I have reachd the maximum of the module I looked to upgrade my zha network to the sonoff 3.0 plus dongle. @le_top & @Hedda have done an excellent job on making it possible to backup and restore zigbee networks. But this only works if your current dongle/module/coordinator is setup on /dev/tty/USB. If not the your still stuck with re-configuring all devices and all automation’s afterwards.

So my idea was to first assign my current coordinator to dev/tty/USB0 and hope that my zha network doesn’t change and then to back up and restore to a new dongle using the “zha_toolkit”

Question is, how do I assign dev/tty/usb0 to my existing coordinator?

hi
the zha_toolkit backup method uses the ZHA/zigpy setup itself, so if that is working, the backup should work. The port is specified in the HA configuration for ZHA.

In the hidden file /config/.storage/core.config_entries, I have the following where the port is listed and this is a configurtion made using the UI, at least when the device is added:

        "entries": [
            {
                "entry_id": "e876e09df16c5319d7a09650f914276c",
                "version": 3,
                "domain": "zha",
                "title": "TI CC2531 USB CDC, s/n: __0X00124B00016A410C - Texas Instruments",
                "data": {
                    "radio_type": "znp",
                    "device": {
                        "path": "/dev/ttyACM0",
                        "flow_control": null,
                        "baudrate": 115200
                    }
                },
                "options": {
                    "custom_configuration": {
                        "zha_options": {
                            "consider_unavailable_mains": 900,
                            "enable_identify_on_join": false,
                            "consider_unavailable_battery": 24000
                        }
                    }
                },
                "pref_disable_new_entities": false,
                "pref_disable_polling": false,
                "source": "user",
                "unique_id": null,
                "disabled_by": null
            },

I do not know how you can reconfigure that using the UI: disable the integration to have acces to its configuration?

Worst case, I would stop HA, make a copy of the hidden configuration file, edit the port configuration and restart HA.

1 Like

Yep indeed the backup works great.
It’s the restore that doesn’t. While the CC2531 is dev/tty/acm0 the sonoff gets assigned dev/tty/usb0 if I remember right. The restore function does then not know where to restore too.

{
                "entry_id": "af376cf0ab18b806adf90f2b2a1c0100",
                "version": 3,
                "domain": "zha",
                "title": "TI CC2531 USB CDC, s/n: __0X00124B0014DA293B - Texas Instruments",
                "data": {
                    "radio_type": "znp",
                    "device": {
                        "path": "/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0014DA293B-if00",
                        "baudrate": 115200,
                        "flow_control": null
                    }
                },
                "options": {},
                "pref_disable_new_entities": false,
                "pref_disable_polling": false,
                "source": "user",
                "unique_id": null,
                "disabled_by": null
            }

this what I have in the hidden storage config. Maybe I’ll try your suggestion and see what happens. Keeping my fingers crossed in that case that I don’t make things worse :wink:

If you make a copy of the configuration first, and why not a recursive copy of .storage to storage_bak you should be fine (cp -Rp .storage storage_bak)

Ok i’ll give that a try tonight. and let you know.
I use pathfinder for mac mostly to avoid cli as i’m not too familiar with all the commands :wink: :innocent:

So I changed the path

"/dev/ttyacm0"

Then tried to restore znp_restore but get an “unknown error” return.

so I guess there still something fishy at my end

You’ld need to enable debugging / look at the debug log to get some hints why.

Hi There,

Here’s what I got:

Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/zha_toolkit/znp.py:81
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 4:10:48 PM (1 occurrences)
Last logged: 4:10:48 PM

[547325846624] Error handling message: Unknown error
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 27, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 534, in handle_execute_script
    await script_obj.async_run(msg.get("variables"), context=context)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1253, in async_run
    await asyncio.shield(run.async_run())
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 354, in async_run
    await self._async_step(log_exceptions=False)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 372, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 575, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1630, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1667, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/config/custom_components/zha_toolkit/__init__.py", line 535, in toolkit_service
    raise handler_exception
  File "/config/custom_components/zha_toolkit/__init__.py", line 499, in toolkit_service
    await handler(
  File "/config/custom_components/zha_toolkit/__init__.py", line 582, in command_handler_default
    await default.default(
  File "/config/custom_components/zha_toolkit/default.py", line 33, in default
    await handler(app, listener, ieee, cmd, data, service, params, event_data)
  File "/config/custom_components/zha_toolkit/znp.py", line 81, in znp_restore
    await znp_backup(app, listener, ieee, cmd, current_datetime, service)
TypeError: znp_backup() missing 2 required positional arguments: 'params' and 'event_data'

I guess the last line is important? However I don’t get the option to fill anything in when using the restore.

I did redownload the integration and that yielded the same result.

I just saw your post - the fix for this was released in 0.7.15 a few hours ago.

Hey @le_top no problem.
I haven’t tried again. But will in the near future. And then I’ll let you know.
What I did find is that I can awake some sensors by doing a ieee-ping. Although once they are then again visible they do seem to remain stuck.
My idea was while stile having the CC2531 I could write an automation to reset a sensor when it becomes unavailable. I bit of a work around and tiresome solution but maybe a quick temporary fix. For the odd sensor that keeps dropping off.

greets :wink:

The zha_toolkit.ieee_ping only requests the IEEE address for the device.
Maybe that eventually results in a false indication that the device is available and explains why the device in question is still “stuck”.

Thats probably the reason indeed. At least thats what it looked like at this end. Is there anyway to do a reset OTA if it is stuck like that? Would be really helpful I guess for more sensors and devices.

The problem is that the device is not visible on the network, so you can’t do anything over the air.

The device should recover by itself, but in some cases the device is not working as it should.

Sometimes such devices will rejoin when they are power cycled as they should have code to look for the network they are on on power up. Others simply seem to forget they are on a network. I have a device that may work properly for months, and this night I had to repair it to the network twice while I do not have any other devie doing like that.

Make sure that you device is in good range of a router as well. Bad communication is another reason for devices having difficulties to stay on the network.

Thanks for the explanation. I find zigbee a very complicated system in that it has a lot of these issues.

For instance if I can ping a device and it’s state goes from unavailable to at least giving an indication (while remaining stuck) that for me mean there some sort of a communication.

I think for me it’s the amount of devices have in the network, 31 I think. Most of the sensors if not all of them are connected through routers and well with in range. For instance I have two Philips SML001 and two SML002 the SML001 work fine and the SML002 work well for a couple of hours and then both loose connection. Hence my idea to change coordinator and hope that the sonoff allows more devices. The update of the sonoff coordinator already did meanwhile but it’s just laying here on my desk :wink:

@330chauf, honestly I am waiting for someone who have successfully restored the backup using this script to explain in details, I am currently using CC2531 with 16 devices and 83 entities . I have 2 sonoff 3.0 dongle just laying around and hoping to switch to it without having to re pair and rename the entities from scratch .

I hope someone will soon have a breakthrough .

so you also dev/ttyACM0?

@330chauf, yes:

/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001CD491A6-if20

Subsystem:tty

Device path:/dev/ttyACM0

ID:/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001CD491A6-if20

@330chauf I think that the fact that “ieee_ping” indicates that the device is alive is some kind of bug in zigpy. I guess that your device is a “sleepy” device and that the parent router replying to the network address request. Zigbee internally updaets the last seen date and I guess it also does that on a successfull get network address response while it should not.