Closed agners closed 1 year ago
agners
commented
2 years ago Afaik, for Raspbee II typically config.txt on the first partition needed adjustments. Did you do such adjustments when you first installed it? What serial device did you use to communicate? (ttyAMA0 or ttyS0)
mbrennan
commented
2 years ago @agners alright thanks. I just tried updating the Phoscon Rasbee II firmware to the latest but that didn't seem to help.
I know before I was able to get the Raspbee II to work I had to edit my boot/config.txt and add a couple of different lines in there to disable bluetooth on the Raspberry Pi. This is what was working:
enable_uart=1
dtoverlay=pi3-disable-btI'm trying to experiment with a few different options to see if it causes the device to appear back into HassOS.
I know the device is alive and working since in order to do the firmware update, I booted my Raspberry Pi into a Phoscon Raspbian image, then used their software to manually update the firmware.
Any suggestions on what specific settings I might need in config.txt?
agners
commented
2 years ago The options above should continue to work. Maybe the update got rid of them? Can you check if the options are still present in config.txt?
mbrennan
commented
2 years ago They are indeed there still, even my previous commented out attempts at getting it to work are still there.
agners
commented
2 years ago Downgrading to 7.6 doesn't seem to help either.
Hm, under these circumstances, the fact that it also stopped working on OS 7.6 is really weird to me then.
Did you check the add-on configuration (is it still pointing to the correct UART)? I'd try to bring it to work on 7.6 first. If you figure out what was needed to fix it for 7.6, that likely will also be the hint what went wrong during update (or if maybe something else happened, and it was just a coincidence that it stopped working with the update to 8.0).
mbrennan
commented
2 years ago I've tried a number of combinations of settings in config.txt without success. The addon I'm using is the standard ZHA. I did recently update my Core version to 2022.5.5 from 2022.5.4, but I don't think that would've caused the issue. The addon can't do it's work until it appears via the host OS, correct?
agners
commented
2 years ago The addon I'm using is the standard ZHA.
Ah so you are using the vanilla ZHA integration then. Do you get any information in the Core logs what is wrong?
mbrennan
commented
2 years ago No just this:
Couldn't start deCONZ = dresden elektronik deCONZ protocol: ConBee I/II, RaspBee I/II coordinator
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/serial/serialposix.py", line 398, in _reconfigure_port
orig_attr = termios.tcgetattr(self.fd)
termios.error: (5, 'I/O error')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/zha/core/gateway.py", line 182, in async_initialize
self.application_controller = await app_controller_cls.new(
File "/usr/local/lib/python3.9/site-packages/zigpy/application.py", line 69, in new
await app.startup(auto_form)
File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/zigbee/application.py", line 83, in startup
await self._api.connect()
File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/api.py", line 254, in connect
self._uart = await zigpy_deconz.uart.connect(self._config, self)
File "/usr/local/lib/python3.9/site-packages/zigpy_deconz/uart.py", line 142, in connect
_, protocol = await serial_asyncio.create_serial_connection(
File "/usr/local/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 448, in create_serial_connection
serial_instance = serial.serial_for_url(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/serial/__init__.py", line 90, in serial_for_url
instance.open()
File "/usr/local/lib/python3.9/site-packages/serial/serialposix.py", line 332, in open
self._reconfigure_port(force_update=True)
File "/usr/local/lib/python3.9/site-packages/serial/serialposix.py", line 401, in _reconfigure_port
raise SerialException("Could not configure port: {}".format(msg))
serial.serialutil.SerialException: Could not configure port: (5, 'I/O error')This issue seems to be exactly what I'm experiencing: https://github.com/home-assistant/core/issues/71950 .
However, it seems downgrading to 7.6 works to fix their issue and not mine. I suspect the device path was renamed. Is there any way to interrogate the devices to see which is my Raspee II device? I could try removing the ZHA integration and re-adding it under a different device path, but I'm worried I'll lose my Zigbee pairings and have to re-pair all 40 of my devices.
agners
commented
2 years ago However, it seems downgrading to 7.6 works to fix their issue and not mine. I suspect the device path was renamed.
But that would likely revert back to the previous name when you downgrade to 7.6.
Are you sure you have been using 7.6? Maybe downgrading to an even a older version helps?
Is there any way to interrogate the devices to see which is my Raspee II device? I could try removing the ZHA integration and re-adding it under a different device path, but I'm worried I'll lose my Zigbee pairings and have to re-pair all 40 of my devices.
Isn't the device the title of the integration (the card of ZHA in the integration Configuration page)?
Otherwise you can peek into .storage/core.config_entries. There should be an entry with "domain": "zha", along with its settings.
mbrennan
commented
2 years ago I can try an older version of HassOS. Where can I see the list of versions?
The device title is just "Raspbee II". Thanks for the tip on looking into .storage/core.config_entries, it looks like the device that it was originally configured with is /dev/ttyS0.
This is what's in the system log regarding ttyS0 and AMA0:
[ 1.481738] uart-pl011 fe201000.serial: there is not valid maps for state default
[ 1.481887] uart-pl011 fe201000.serial: cts_event_workaround enabled
[ 1.481965] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 21, base_baud = 0) is a PL011 rev2
[ 1.487960] bcm2835-aux-uart fe215040.serial: there is not valid maps for state default
[ 1.488478] fe215040.serial: ttyS0 at MMIO 0xfe215040 (irq = 22, base_baud = 62500000) is a 16550ttyS0 means mini-UART, and from what I understand Dreseden Electronics recommends to use the full UART (aka ttyAMA0). It is weird that it used to work at one point. But I would try the following:
ttyS0 to ttyAMA0 in .storage/core.config_entries.config.txt and use the following:enable_uart=1
dtoverlay=disable-btSee if that works.
mbrennan
commented
2 years ago I've had some progress doing this although I went about it a slightly different way. Since you mentioned that Dreseden Electronics recommends the full UART, I realized I still had this in my config.txt: dtoverlay=miniuart-bt which I think was causing the device to respond under tyyS0. I removed that line, without adding dtoverlay=disable-bt. So the only thing I had added to config.txt was enable_uart=1. I tried rebooting just to see what effect this might have, without modifying .storage/core.config_entries. To my surprise, ZHA successfully loaded but most of my entities provided through ZHA were unavailable. Next I tried changing ttyS0 to ttyAMA0 in .storage/core.config_entries and rebooted. Several of the entities came back online, but there were still quite a few unavailable. Next, I tried disabling bluetooth via the dtoverlay=disable-bt option in config.txt and rebooted, I saw more entities come back but still a bunch were unavailable. Finally, I installed the latest HassOS 8.0, after this reboot most of my entities are available but several are still unavailable.
Any idea on how to get those devices to come back?
agners
commented
2 years ago I'd say this has nothing to do with the OS/setting anymore, its probably some other reason those went missing. Sometimes just waiting for a bit helps, in worst case pair them again probably helps.
joergwerner63
commented
2 years ago I had similar problems with my RaspBee (version1). ZHA integration could not start. As device /dev/ttyS0 was listend. I'm not 100% sure but I think I did set it up with /dev/ttyS0. Anyway, I deleted the ZHA integration and reinstalled it but this time with /dev/AMA0 and everything is working again. Strange.
roessi
commented
2 years ago Hi all Have the same issue After the Upgrade to 8.1 on my odroid n2+. i tryed reebooting and the extra Upgrade of the deconz Stick with the Windows app. But nothing helps. Ist seams like the usb is Not working on 8.1
agners
commented
2 years ago I had similar problems with my RaspBee (version1). ZHA integration could not start. As device /dev/ttyS0 was listend. I'm not 100% sure but I think I did set it up with /dev/ttyS0. Anyway, I deleted the ZHA integration and reinstalled it but this time with /dev/AMA0 and everything is working again. Strange.
ttyS0 is the mini-UART, and ttyAMA0 is the PL011 UART. If this changed, it means you switched the primary and secondary UART (e.g. by using the doverlay as recommended by dresden electronics. It seems that current/new configuration uses the PL011 UART, which is the recommended setup :+1:
See also: https://www.raspberrypi.com/documentation/computers/configuration.html#primary-and-secondary-uart
agners
commented
2 years ago @roessi
Hi all Have the same issue After the Upgrade to 8.1 on my odroid n2+. i tryed reebooting and the extra Upgrade of the deconz Stick with the Windows app. But nothing helps. Ist seams like the usb is Not working on 8.1
This thread is about Raspberry Pi related problems with the RaspBee II. Your issue seems similar to #1795, can you report your details there? Can you also try to downgrade back to 7.6 to see if it fixes the problem again?
roessi
commented
2 years ago I made some Research last night. It looks like kernel version 5.15.41 is causing the problem On my Odroid n2 the 5V of the USB port are switched off. No idea if this can be fixed with a setting in the linux config, or if it's a driver problem. I don't know enough about linux for that, but as a result, no USB device is recognized on the Odroid.
Albruaje
commented
2 years ago I have the same problems with my RaPi4 haos 8.0 and 8.1 with a Dresden Raspbee II, using Mosquito and Zigbee2mqtt. No way to have zigbee items again. Have tried all the proposals above. Thanks that I cloned my SD card before upgrading and can easily restore.
enjikaka
commented
2 years ago Same as https://github.com/home-assistant/operating-system/issues/1751 I believe.
Need to remove dtoverlay from config.txt before upgrading OS; then enable it after again. Still stuck on 7.2 here due to this.
github-actions[bot]
commented
2 years ago There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
The same issue happened to me after upgrading to Home Assistant Operating System to 8.0. My
ConbeeRaspbee II doesn't seem to be recognized. I can't see any other devices in the hardware section (recently moved around in Home Assistant Core), under Settings -> System -> Hardware. The only thing that's listed there is "Raspberry Pi 4 rpi4-64".I've tried rebooting the host and unplugging and replugging in my Conbee II stick. I'm not using an extension cable.
How can I roll back the Home Assistant OS to the previous version?
Originally posted by @mbrennan in https://github.com/home-assistant/operating-system/issues/1795#issuecomment-1131607054
Information added by @agners from #1795
This is copy/pasted from System -> Logs with the 'Host' drop down:
Sorry, I realized it's not a Conbee II stick, it's a Raspbee II integrated device onboard. Everything was working fine prior to the upgrade. After the upgrade it stopped working. Downgrading to 7.6 doesn't seem to help either.