search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.88k stars 489 forks source link

Raspberry Pi 4? #1643

Closed FezVrasta closed 4 years ago

FezVrasta commented 5 years ago

Hi, I was wondering if the RaspBee shield is compatible with RPi 4 B+? (both firmware and hardware)

Thanks.

00lex commented 5 years ago

Yes it it!

Kane610 commented 5 years ago

A related question, with the rpi4 new architecture does the shield conflict with BT?

00lex commented 5 years ago

I never use bt or wifi on a pi. but any 2.4ghz disturb other 2.4ghz signals. bt, wifi and zigbee use 2,4ghz

Kane610 commented 5 years ago

Sure. But iirc it wasn't possible to run both at the same time before

ebaauw commented 5 years ago

I’m waiting for the 4GB model to become available, so haven’t tried yet myself. Would love to hear your experiences.

I would expect better VNC performance and faster compilation of the REST API plugin. I don’t expect noticeable differences in production: my 3B+ handles deCONZ (gui), two homebridge instances and opentherm monitor well, at less than 50% CPU load.

Looks like Raspberry released the new OS, buster, too early, not sure I would want to move production yet. There’s no buster package for deCONZ yet, but it looks like the stretch package works on buster, see #1633. I am concerned about the increased power consumption, or rather the increased temperature because of that. I found the RaspBee hinders the airflow in the Pi 3 more than I could compensate with a set of heatsinks, see #147.

00lex commented 5 years ago

my pi4 runs now since 3 days without issues. a had a lot of issues with my clean install but that's my personal problem. finally everything is as before. I run deconz, pimatic, plexserver, flexget, motioneye, flexget, jdownloader, pihole, timemachine over smb, and nextcloudpi@docker. the only thing im wanting for is deconz repo and new firmware for usb-boot and https://www.tomshardware.com/news/raspberry-pi-4-firmware-update-tested,39791.html

Gbit and usb3 makes me happy! I get constant 70-80MB/s over smb (=big files). rpi4 (cable) > fritzbox-router > macbook (3x3 mimo / one wall between)

sftp is much slower 30-40MB/s. TimeMachine backups over smb is also too slow 10-30MB. maybe because of wrong smb config (?). but recovering files runs fast

SwoopX commented 5 years ago

Regarding running Raspbee and BT simultaneously: My Pi Zero W handles it very well so I'd assume it's no different on the Pi 4...

ebaauw commented 5 years ago

Any experiences yet with interference caused by USB 3.0 devices? See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1598#issuecomment-508904699.

00lex commented 5 years ago

no. I had too concerns on this. but I use raspbee and have 4cm distance to the USB port where I use a SSD drive

EDIT: I read the paper https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1598#issuecomment-508904699 and my conclusion is:

don't worry. people use their conbee sticks long before rpi4 with PCs. most often there are other issues. I use very often usb3 hard drives and my laptop is only connected via wifi and I never noticed issues with my signal. if you are looking for problems, you will also find which ones :) enjoy your rpi4. I love it!

olemr commented 5 years ago

I have really struggled the last day to get an 11 node network stable on my Pi 4 using a ConBee stick and deCONZ .66. image

My problems was twofold. First was in my eagerness waiting for my Pi 4 (4Gb) to arrive in the mail I build my network on a Windows PC a few days before it arrived and created a backup. After my Pi 4 arrived, I installed Raspbian using NOOBS and installed deCONZ 2.0.5.66 from here and restored the backup. That did not go well. After several reboot attempts with network coming and going I was finally unable to log in, and ended up deleting the whole database (.local/share/dresden-elektronik/deCONZ/zll.db )and started afresh. (I still have this backupfile and the database produced should anyone be interested).

After including all nodes again, things looked OK, but not for long. I was now running my Pi 4 quite close to my WiFi router with the ConBee in one of the 2 USB2 slots on the Pi 4. After a while, all light-nodes became unreachable and unresponsive (remotes assigned to lights still worked OK, also switches and sensors). I picked up on the tip using an USB extension cord and used that (1.5m) for the ConBee. Things looked better, but after a few hours all green connections in the network diagram disappeared. All nodes unreachable. Since this looked like a stability issue and the Pi 4 is running very hot, I pulled out a powered USB2 HUB and attached the ConBee to that. Jury is still out, but 2 hours on it looks fine. Will report back with how it goes.

If anybody has any ideas what other things to check, please let me know.

manup commented 5 years ago

Since this looked like a stability issue and the Pi 4 is running very hot, I pulled out a powered USB2 HUB and attached the ConBee to that. Jury is still out, but 2 hours on it looks fine. Will report back with how it goes.

That sounds concerning, do you use the official Raspberry Pi USB-C power adapter?

Which firmware are you running? It should be at least 0x26490700 for stable connection.

We have some new troubleshooting notes online, but looks like you already checked most of the steps:

https://phoscon.de/en/support#conbee2-connection-issues

olemr commented 5 years ago

I'm using this power supply as recommended and bundled by my re seller. Since this is the ConBee Classic (not the II) I believe I'm on the latest firmware: image

The ConBee has been used as a sniffer previously, but I re-flashed with the version above. And, by the way, network still looks good.

manup commented 5 years ago

Ah ok, indeed that's the latest firmware for ConBee/RaspBee.

Not sure about the power adapter, when I visit Kjells Raspberry Pi 4 page they suggest: https://www.kjell.com/se/produkter/dator-natverk/raspberry-pi/raspberry-pi-usb-c-natadapter-3-a-p88081

The reason I'm bringing this up is that Raspberry Pi 4 seems to have big issues with many USB-C adapters due a technical design flaw. Interesting read: https://hackaday.com/2019/07/16/exploring-the-raspberry-pi-4-usb-c-issue-in-depth/

olemr commented 5 years ago

The reason I'm bringing this up is that Raspberry Pi 4 seems to have big issues with many USB-C adapters

Read the article you linked to, and it seems to be a 'binary' power issue. It either works or it don't. The power brick itself does not run hot, so it seems to cope with the load. For the Pi 4 itself, I need to look into some heat-sinks. The SoC and the USB2/3+Eth metallic shielding is very hot to the touch.

manup commented 5 years ago

Following looks similar: https://www.jeffgeerling.com/blog/2019/raspberry-pi-4-needs-fan-heres-why-and-how-you-can-add-one

I'm currently in vacation can't wait to get my hands on the RPi 4 for testing :)

olemr commented 5 years ago

Nice find @manup . I'm on vacation too, but brought the Pi 4 and my Surface and some Zegbee nodes. :-) Currently setting up Samba shares and openHAB ... Zigbee network still OK with ConBee on the powered HUB. I will not connect to any HDMI ports (VNC/Samba only) so hopefully it will not melt on me.

olemr commented 5 years ago

Will report back with how it goes.

After connecting the ConBee with a powered USB2 HUB, network has been 100% stable.

Turning RPi4 WiFi and/or BT off had no effect when I tried without the powered HUB. I have a USB3 HUB connected to USB3 with 4 spinner disks attached. Not sure if that is related. Eth connected to a Gbit switch.

manup commented 5 years ago

After connecting the ConBee with a powered USB2 HUB, network has been 100% stable.

Interesting, it adds to the conclusion that increasing the distance of ConBee or any 2.4 GHz radio to active USB 3 devices improves reliability.

I have a USB3 HUB connected to USB3 with 4 spinner disks attached. Not sure if that is related. Eth connected to a Gbit switch.

Likely related to the USB 3 vs. 2.4 GHz problems mentioned in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1598#issuecomment-508904699

olemr commented 5 years ago

Interesting, it adds to the conclusion that increasing the distance of ConBee or any 2.4 GHz radio to active USB 3 devices improves reliability.

Yes, with ConBee connected straight into the RPi4 network died within minutes. With a 1.5m USB extension it lastet a few hours. With the powered HUB: rock steady.

So it could also be a power related problem, or the 1.5m extension was too long. (only one I had at hand)

ebaauw commented 5 years ago

or the 1.5m extension was too long

I've been using a 5m USB extension cable between a RaspBerry Pi 3B and a (v1) ConBee for ZShark sniffing without any issues.

flobernd commented 5 years ago

I'll add to this issue and close my duplicate one.

Some facts:

Hope there will be a solution which does not involve extension cables.

ebaauw commented 5 years ago

Finally, the 4GB model is available. Got mine yesterday ;-).

Had some issues with the headless setup. Turns out, you need to comment out dtoverlay=vc4-fkms-v3d in /boot/config.txt, or the screen resolution will stick to (I think it was) 1280x720.

Installed deconz and deconz-dev packages from http://phoscon.de/apt/deconz buster-beta/main armhf (the buster packages seem to be available now). I NFS-mounted (my fork of) the deCONZ REST API plugin package, that I keep on my MacBook Pro (same setup as my Pi 3B+ dev/test machine). As mentioned earlier, I want to use the Pi 4B for compiling the REST API plugin; I'm not running deCONZ on it (yet?).

$ make clean
...
$ time make -j3
...
real    3m34.280s
user    8m0.654s
sys 0m39.617s

Holy cow, that's twice as fast as on my Pi 3B+. CPU temperature rose to 76°C (no throttling as that only kicks in at 80°C on the Pi 4B). I haven't installed any heat sinks nor fans yes, but I do keep the case lid off (if I don't, even the idle temperature rises to 80°C).

With make -j4, the compilation takes 3m7.366s and CPU temp rises to 79°C (still no throttling!).

ebaauw commented 5 years ago

OK, installed deCONZ (using a ConBee II) and homebridge on the Pi 4B and moved it to the closet with my other Raspberries, macMini server, and some other network stuff. With the closet door closed, it gets close to 40°C in there. The Pi 4B doesn't like that: it rises to 85°C, throttling back to 750 to 1000 MHz (from 1500 MHz). Double-checking my two Pi 3B+ machines, also running deCONZ (with a RaspBee) and homebridge, with heat sinks on the SoC, I/O and memory chips. They run to 65°C and throttle back to 1200MHz (from 1400 MHz). With the door open, the ambient temperature drops to slightly above 30°C and the Pi 4 stays just under 80°C and the Pi 3B+ just under 60°C.

Got myself a Fan SHIM and installed that on the Pi 4B. For now just the hardware. The fan starts running as soon the Pi powers on. It is audible, but not loud - far better than I'd hoped for. Testing on my desk, It seems to lower the temperature by ~25°C, idle (< 10% CPU) as well as when compiling the REST API plugin with make -j4. Will move it back to the closet to see what it'll do overnight.

The Fan SHIM installs "over" the GPIO pins: it contains holes through which pins 1-12 pierce. You could still install a HAT on top of the Fan SHIM, but you'd need a booster header to raise the HAT above the fan.

I'm not sure if it will work in conjunction with a RaspBee: they physically occupy the same pins. From the "documentation" (Use the Source, Luke), I understand the SHIM uses GPIO 18 to control the Fan and GPIO 17 for the push button. The (multi-coloured) LED seems to be controlled through I2C over GPIO 2 and 3. I assume the RaspBee uses GPIO 14 and 15 for the serial interface, so no conflict there. But I understand from #1718, that the RaspBee also uses GPIO 18 for a hardware reset (#1718). Maybe it just works as long as you don't try and control the fan through GPIO 18. @manup, any thoughts on this?

BTW, the ConBee II seems happy, connected directly to a USB2 port. I've only paired a single light, though, and have nothing connected to the USB3 ports.

flobernd commented 5 years ago

@ebaauw I created this issue exactly because of the RaspBee and FAN Shim combination.

The RaspBee worked fine for me (even while an USB3 device was plugged!) but I was totally unable to control the FAN Shim. Well .. there was a small time window until the deconz service started. The bad thing tho was that the fan sometimes started spinning after reboot and sometimes not.

After this problems, I bought the ConBee II and run into the USB3 issue which is kinda frustrating.

Edit: The FAN Shim uses pin 14 and 15 (and not 2+3) for a kind of software emulated SPI, so controlling the LED was not possible as well while having the RaspBee plugged on top.

urbozz commented 5 years ago

I have tried running the RaspBee using the Hass.io add-in on a Pi 4, without success.

deCONZ is seeing the RaspBee with the most current firmware, however it cannot see any Zigbee devices. I tried resetting the gateway but this did not work and was still unable to find any Zigbee devices. Moving back to the Pi 3b, all works correctly.

I have in the config.txt 

enable_uart=1
dtoverlay=pi3-miniuart-bt
flobernd commented 5 years ago

deCONZ is seeing the ConbBee with the most current firmware, however it cannot see any Zigbee devices

That sounds exactly like the USB3 problem. Do you have any USB3 devices plugged into the Pi or nearby?

urbozz commented 5 years ago

That sounds exactly like the USB3 problem. Do you have any USB3 devices plugged into the Pi or nearby?

No USB3 or any other USB devices plugged in.

edit: should read RaspBee, not Conbee!

ebaauw commented 5 years ago

The RaspBee worked fine for me (even while an USB3 device was plugged!) but I was totally unable to control the FAN Shim.

@flobernd, did you use a booster header, or did the RaspBee fit without one? I'm planning to get a booster header and cut the header's GPIO18 pin. That should leave GPIO18 connected to the Fan SHIM, but not to the RaspBee. I hope this will enable me to control the fan while deCONZ is running. As the RaspBerry is locked away in a closet, I don't care too much for the button nor the LED.

The bad thing tho was that the fan sometimes started spinning after reboot and sometimes not.

I find too that sometimes it doesn't feel like starting, also when using the service written in Python. For now, I changed the service parameters to set the lower bound to 50°C instead of 55°C, so it keeps running all the time.

The FAN Shim uses pin 14 and 15 (and not 2+3) for a kind of software emulated SPI, so controlling the LED was not possible as well while having the RaspBee plugged on top.

Indeed. I found the pin layout on https://pinout.xyz/pinout/fan_shim. Unfortunately, they don't list the RaspBee. @manup, would it be possible to add it? See https://github.com/gadgetoid/Pinout.xyz#contributing.

manup commented 5 years ago

@manup, would it be possible to add it? See https://github.com/gadgetoid/Pinout.xyz#contributing.

Cool, didn't know that site, I'll create a PR.

ebaauw commented 5 years ago

Installed fan shims in my Raspberry Pi 3B+ machines, running deCONZ using a RaspBee. The RaspBee fits nicely on top top the fan shim, without using a booster header. Of course, I had to remove the heat sinks from the SoC. The RaspBee covers about one third of the fan, but that doesn't seem to effect the cooling too badly. The official Raspberry Pi case still fits, but I leave the lid off for better air flow.

I still run stretch on the Pi 3B+. I couldn't get the fan shim service to work, due to Python version incompatibilities. I can control and read the fan manually using pigpio and by writing to/reading from /sys/class/gpio/gpio18/value (after exporting the gpio and setting its direction to out). deCONZ continues to run, and I don't see anything weird in the log. Haven't tried the shim and RaspBee on the Pi 4B, though.

ghost commented 5 years ago

For the people who managed to get their Raspbee working on the Raspberry Pi 4 do you mind sharing your configuration and what you did to get it working.

I've been trying to get Raspbee working on my raspberry pi 4 for the past 2 days now, scouring every possible forum and search result from google, but to no avail.

Below is my setup:

The following docker-compose.yaml files are used: homeassistant:

version: '3'
services:
  homeassistant:
    container_name: home-assistant
    image: homeassistant/raspberrypi4-homeassistant:0.97.2
    ports:
      - 8123:8123
    volumes:
      - /home/pi/homeassistant:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Netherlands/Amsterdam
    restart: always

pihole:

version: "3"
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "8080:80/tcp"
      - "8443:443/tcp"
    environment:
      TZ: 'Netherlands/Amsterdam'
      WEBPASSWORD: 'CYfUhcwZN4mJgJtt2n!HX%Q!Q*x%24*'
    # Volumes store your data between container upgrades
    volumes:
       - './etc-pihole/:/etc/pihole/'
       - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
    dns:
      - 127.0.0.1
      - 1.1.1.1
    cap_add:
      - NET_ADMIN
    restart: always

deconz:

version: "3"
services:
  deconz:
    image: marthoc/deconz
    container_name: deconz
    network_mode: host
    restart: always
    volumes:
      - ~/.local/share/dresden-elektronik/deCONZ:/root/.local/share/dresden-elektronik/deCONZ
      - /etc/localtime:/etc/localtime:ro
    devices:
      - /dev/ttyAMA0
    environment:
      - DECONZ_DEVICE=/dev/ttyAMA0
      - DECONZ_WEB_PORT=80
      - DECONZ_WS_PORT=443
      - DEBUG_INFO=1
      - DEBUG_APS=0
      - DEBUG_ZCL=0
      - DEBUG_ZDP=0
      - DEBUG_OTAU=0

I've also modified the /boot/config.txt . with the following at the end of the file (has a blank line at the end):

enable_uart=1
dtoverlay=pi3-miniuart-bt
dtoverlay=uart0-full
core_freq=250

and configured user access rights of the serial interface (raspi-config) as specified here https://phoscon.de/en/raspbee/install#docker

I can access the Phoscon-GW (via the raspberry ip) and have also reset the password. On the Settings > Gateway page the version number is 2.05.66 / 16/06/2019 but firmware states not connected. As a note in Settings > Gateway > Advanced I cannot change the ZigBee channel, currently states 0 (if I try to change this I get a never ending spinning clog), and Network id is unknown.

The logs from my deconz container show the following:

[marthoc/deconz] Starting deCONZ...
[marthoc/deconz] Current deCONZ version: 2.05.66
[marthoc/deconz] Web UI port: 80
[marthoc/deconz] Websockets port: 443
[marthoc/deconz] VNC Disabled
libpng warning: iCCP: known incorrect sRGB profile
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
15:23:58:564 HTTP Server listen on address 0.0.0.0, port: 80, root: /usr/share/deCONZ/webapp/
15:23:58:577 CTRL. 3.16.215:23:58:639 dev /dev/ttyAMA0
15:23:58:639 COM: /dev/ttyAMA0 / serialno:
15:23:58:639 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:23:58:639 ZCLDB init file /root/.local/share/dresden-elektronik/deCONZ/zcldb.txt
15:23:58:749 parent process /bin/sh
15:23:58:750 gw run mode: docker
15:23:58:750 GW sd-card image version file does not exist: /root/.local/share/dresden-elektronik/deCONZ/gw-version
15:23:58:750 sd-card cid: <xxxxxxxxxxxxxx redacted xxxxxxxxxxxxxx>
15:23:58:751 DB sqlite version 3.16.2
15:23:58:753 DB PRAGMA page_count: 30
15:23:58:753 DB PRAGMA page_size: 4096
15:23:58:753 DB PRAGMA freelist_count: 0
15:23:58:753 DB file size 122880 bytes, free pages 0
15:23:58:753 DB PRAGMA user_version: 6
15:23:58:753 DB cleanup
15:23:58:754 DB create temporary views
15:23:58:763 don't close database yet, keep open for 900 seconds
15:23:58:764 started websocket server at port 443
15:23:58:767 discovery updated announce interval to 10 minutes
15:23:58:769 found node plugin: libde_rest_plugin.so - REST API Plugin
15:23:58:772 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
15:23:58:782 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
15:23:58:812 dev /dev/ttyAMA0
15:23:58:812 COM: /dev/ttyAMA0 / serialno:
15:23:58:812 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:23:58:985 Error: invalid command
15:23:59:323 device state timeout ignored in state 2
15:23:59:996 Error: invalid command
15:24:00:274 device state timeout ignored in state 2
15:24:00:907 Error: invalid command
15:24:01:225 device state timeout ignored in state 2
15:24:01:917 Error: invalid command
15:24:02:221 device state timeout ignored in state 2
15:24:02:928 Error: invalid command
15:24:03:220 device state timeout ignored in state 2
15:24:03:839 Error: invalid command
15:24:04:100 dev /dev/ttyAMA0
15:24:04:221 device state timeout (handled)
15:24:04:314 Announced to internet
15:24:04:314 discovery server date: Sun, 18 Aug 2019 13:24:04 GMT
15:24:04:314     local time seems to be ok
15:24:04:314 discovery found version 2.04.35 for update channel stable
15:24:04:720 wait reconnect 15 seconds
15:24:04:721 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state
15:24:04:721 device state timeout ignored in state 1
15:24:05:720 wait reconnect 14 seconds
15:24:06:720 wait reconnect 13 seconds
15:24:07:720 wait reconnect 12 seconds
15:24:08:720 wait reconnect 11 seconds
15:24:09:720 wait reconnect 10 seconds
15:24:10:322 scan skip host .226
15:24:10:721 wait reconnect 9 seconds
15:24:11:720 wait reconnect 8 seconds
15:24:12:721 wait reconnect 7 seconds
15:24:13:720 wait reconnect 6 seconds
15:24:14:298 dev /dev/ttyAMA0
15:24:14:721 wait reconnect 5 seconds
15:24:15:721 wait reconnect 4 seconds
15:24:16:721 wait reconnect 3 seconds
15:24:17:721 wait reconnect 2 seconds
15:24:18:720 wait reconnect 1 seconds
15:24:18:796 dev /dev/ttyAMA0
15:24:18:796 COM: /dev/ttyAMA0 / serialno:
15:24:18:796 COM: --dev: /dev/ttyAMA0 (RaspBee)
15:24:18:951 Error: invalid command
15:24:19:283 device state timeout ignored in state 2
15:24:19:961 Error: invalid command
15:24:20:234 device state timeout ignored in state 2
15:24:20:872 Error: invalid command
15:24:21:220 device state timeout ignored in state 2
15:24:21:883 Error: invalid command
15:24:22:220 device state timeout ignored in state 2
15:24:22:893 Error: invalid command
15:24:23:220 device state timeout ignored in state 2
15:24:23:904 Error: invalid command
15:24:24:220 device state timeout (handled)
15:24:24:295 dev /dev/ttyAMA0
15:24:24:721 wait reconnect 15 seconds
15:24:24:721 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state
15:24:24:721 device state timeout ignored in state 1
15:24:25:721 wait reconnect 14 seconds
15:24:26:720 wait reconnect 13 seconds
15:24:27:720 wait reconnect 12 seconds
15:24:28:720 wait reconnect 11 seconds
15:24:29:721 wait reconnect 10 seconds
15:24:30:720 wait reconnect 9 seconds
15:24:31:720 wait reconnect 8 seconds
15:24:32:721 wait reconnect 7 seconds
15:24:33:720 wait reconnect 6 seconds
15:24:34:284 dev /dev/ttyAMA0
15:24:34:721 wait reconnect 5 seconds
15:24:35:721 wait reconnect 4 seconds
15:24:36:720 wait reconnect 3 seconds
15:24:37:721 wait reconnect 2 seconds
15:24:38:720 wait reconnect 1 seconds
...

I tried to connect a Philips Hue motion sensor but this fails to connect (expected with the logs above). I'm not sure what I'm missing but any help with trying to figure why I cannot get the Raspbee to work out would be greatly appreciated (hoping it's not cause I'm running on teh Raspberry Pi 4). If I've missed out any info which could help with figuring this out more than happy to provide more.

Thanks for any help in advance.

FezVrasta commented 5 years ago

On my RPi the RaspBee was assigned on ttyS0

ghost commented 5 years ago

@FezVrasta Thanks for the reply. Unfortunately I've tried that but doesn't seem to work either.

20:23:38:137 started websocket server at port 443
20:23:38:140 discovery updated announce interval to 10 minutes
20:23:38:143 found node plugin: libde_rest_plugin.so - REST API Plugin
20:23:38:145 found node plugin: libde_signal_plugin.so - Signal Monitor Plugin
20:23:38:155 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
20:23:38:186 dev /dev/ttyAMA0
20:23:38:186 COM: --dev: /dev/ttyS0 (RaspBee)
20:23:38:696 device state timeout ignored in state 2
20:23:39:646 device state timeout ignored in state 2
20:23:40:599 device state timeout ignored in state 2
20:23:41:549 device state timeout ignored in state 2
20:23:42:532 device state timeout ignored in state 2
20:23:43:267 New websocket 192.168.1.20:63532 (state: 3)
20:23:43:470 dev /dev/ttyAMA0
20:23:43:532 device state timeout (handled)
20:23:43:863 Announced to internet
20:23:43:863 discovery server date: Sun, 18 Aug 2019 18:23:43 GMT
20:23:43:863     local time seems to be ok
20:23:43:863 discovery found version 2.04.35 for update channel stable
20:23:44:032 wait reconnect 15 seconds
20:23:44:032 void zmMaster::handleStateIdle(zmMaster::MasterEvent) not connected goto OFF state
20:23:44:033 device state timeout ignored in state 1
20:23:45:032 wait reconnect 14 seconds
20:23:46:032 wait reconnect 13 seconds
20:23:46:834 scan skip host .172
20:23:47:032 wait reconnect 12 seconds
20:23:48:032 wait reconnect 11 seconds
20:23:49:032 wait reconnect 10 seconds
20:23:50:032 wait reconnect 9 seconds
20:23:51:032 wait reconnect 8 seconds
20:23:52:032 wait reconnect 7 seconds
20:23:53:032 wait reconnect 6 seconds
20:23:53:564 dev /dev/ttyAMA0
20:23:54:032 wait reconnect 5 seconds
20:23:55:032 wait reconnect 4 seconds
20:23:56:032 wait reconnect 3 seconds
20:23:57:032 wait reconnect 2 seconds
20:23:58:032 wait reconnect 1 seconds
20:23:58:108 dev /dev/ttyAMA0
20:23:58:108 COM: --dev: /dev/ttyS0 (RaspBee)

I've changed both the devices and var DECONZ_DEVICE to /dev/ttyS0 in my docker-compose.yaml file so not sure why it still references /dev/ttyAMA0 in the logs.

flobernd commented 5 years ago

@manup

@flobernd, did you use a booster header, or did the RaspBee fit without one?

I did use a booster header, but it should fit fine without. Cutting PIN18 on the booster is a good idea. At least it's worth a try.

I find too that sometimes it doesn't feel like starting, also when using the service written in Python. For now, I changed the service parameters to set the lower bound to 50°C instead of 55°C, so it keeps running all the time.

I created a small service in C which works much better than the original Python script and uses less CPU resources: https://github.com/flobernd/raspi-fanshim/blob/master/examples/FanshimService.c

Steve-gnome commented 4 years ago

My Pi4 also recognises the Raspbee on ttyS0, shows firmware connected etc but won't detect anything.

manup commented 4 years ago

Do you have the latest RaspBee firmware version 0x26330500 installed?

Note updating on Raspberry Pi 4 requires an extra step as described in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1762

FezVrasta commented 4 years ago

Is there any issue on running RaspBee on ttyS0 rather than ttyAMA0?

mef-hamburg commented 4 years ago

Hi everyone. I have also have a problem with running the Raspbee on a Raspberry Pi 4. Tried both in Raspian (where I managed to update the firmware) and in Hass.io. The deconz gui sees the raspbee, but no other devices. Anyone managed to get the raspbee working on a Raspberry Pi 4???

TheTimeWalker commented 4 years ago

Yup, like others I'm tearing my hairs out making the whole thing work on my Pi 4.

I'm using a Raspbee on it with the latest update 0x26330500 installed. It feels like the range is drastically limited, so much that it loses any connection to other Zigbee devices. I do have an bootable USB stick that starts my Raspbian Buster instance but I have tried plugging it into USB3 and USB2 slots without any better results. I have also tried using 65 and 66 of deConz (Docker installation) but that didn't help much either. The logs don't help much too with many of the lines just repeating that sending has been delayed. The only real "error" that appears is this: 13:37:30:194 0x00158D0000AFF2BA error APSDE-DATA.confirm: 0xA7 on task

The result in my GUI often times looks like this: image

I have tried moving the Raspberry to different locations making sure the line of sight is pretty much not blocked. But for example the "Wohnzimmer Haupt" is only 2m apart from the router and it still tends to lose connection (it's sadly the best responding one).

Before with the Pi 3 I didn't have that many issues. The two lamps always worked fine and it never lost connection. Now the "Stehlampe" lamp never wants to connect correctly and pairing new lights is a big pain.

manup commented 4 years ago

I do have an bootable USB stick that starts my Raspbian Buster instance but I have tried plugging it into USB3 and USB2 slots without any better results.

If possible, can you check if the signal issue persists when using just an sd-card but no USB stick or disk. USB 3.0 devices may cause really bad interference with 2.4 GHz radios.

The usage of USB extension cable to bring some distance between the USB devices and the radio often helps a lot.

Please also check that the serial interface is configured properly as described in step (1) of the installation guide https://phoscon.de/en/raspbee/install#raspbian deCONZ should show that /dev/ttyS0 is used when the interface is configured correctly.

TheTimeWalker commented 4 years ago

I'll check out if there's any difference if I go with SD card only. Though I did use USB boot with Pi 3 with the same stick and it had no issues. I guess Pi 3 and 4 handle it differently? Also yeah, it's running over /dev/ttyS0 that's why I can at least access the gateway on Phoscon and the deCONZ GUI.

TheTimeWalker commented 4 years ago

I have tried moving over to the SD card and have nothing plugged in, yet I'm still having issues connecting to lights with logs filling up like this:

17:59:50:779 delay sending request 81 dt 19 ms to 0x00158D00011E88E9, cluster 0x0004
17:59:50:828 0x00158D00011E88E9 error APSDE-DATA.confirm: 0xA7 on task

As a side note: Reachability should be fine as when I click on "Turn Off", all lights get turned off. IIRC that's a general unicast signal which the lamps seem to fetch without issues.

I also turned off Wifi and BT which moves Raspbee over to ttyAMA0 now. And yet I'm still having issues with it.

Final edit for this post: Okay so after trying out more, with SD card and disabled Wifi, BT and UART BT service, I'm getting a lot better signal out of it then before. Now the thing is that with these changes I actually have to use it over AMA instead of S0 so there's a possibility that the USB wasn't at fault yet. I'm going to test it out some more but one thing I can say is that it has nothing to do with the issue at hand (Pi 4) so I'm not going to further clutter this here.

ebaauw commented 4 years ago

@flobernd, I continue to have a love/hate relationship with my fan shims. The fans wouldn't start anymore; they tried to start, but would stop after a view rounds, presumably because they encountered too much resistance. I double-checked that the fans run free; it was the fan mechanism itself. You can check by taking the shim out and blowing air through the fan's blades: it stops rather abruptly.

After applying WD40 contact spray to the fan mechanism, they run smoothly again, and I haven't seen any stalls (yet... knock on wood).

flobernd commented 4 years ago

@ebaauw My first Fanshim died in the meantime (probably got contact to a wrong PIN while tinkering around). I'm now using the RPI CASE ALU07F case which even yields better cooling results. I'm planning to connect just the board of my 2nd Fanshim to the fans of the new case in order to control them, but did not have time for that yet.

@manup Is there any update regarding the USB problem? I would still love to use the ConBee II on my Rasbperry 4 without the USB extension cable.

manup commented 4 years ago

Small update: The new bootloader and firmware is still cooking. It's quite a challenging task since we do a complete rewrite of the old bootloader, in order to be able to test it properly and be sure that all known problems are addressed.

In constrast to application firmware updates, updating the bootloader itself is usually very dangerous since that could brick the device, we therefore currently figuring out code which could self-heal a broken update.

I can't provide a strict ETA yet, but I hope that it's a matter of weeks for an early release.

Please keep in mind that neither the new bootloader nor application firmware can fix physical constraints caused by USB 3.0 interference, albeit the new firmware will do a much better job to startup and keep being connected, a ConBee near USB 3.0 devices will likely always have a weak signal, so the recommendation of using an USB extension cable remains.

FezVrasta commented 4 years ago

What about the unreachable devices that everybody are reporting lately on this repo? Are you going to address the problem?

manup commented 4 years ago

Absolutely, but I'll need more testing to investigate and get a complete image of the issue. I'm not sure yet if it is related to firmware since there were reports that only parts of the devices are affected but not all (which would indicate the mentioned firmware startup issues).

CaseyRo commented 4 years ago

@Unibond7 sorry for the late response, but I also had some problems getting this thing started -- for whatever reason this worked for me;

docker run -d \
   --name=deconz-bash \
   --net=host \
   --restart=always \
   -v /etc/localtime:/etc/localtime:ro \
   -v ~/deCONZ:/root/.local/share/dresden-elektronik/deCONZ \
   --device=/dev/ttyAMA0 \
   --device=/dev/ttyS0 \
   marthoc/deconz

Now slowly adding stuff like VNC etc to see if the rest also works...

manup commented 4 years ago

Indeed. I found the pin layout on https://pinout.xyz/pinout/fan_shim. Unfortunately, they don't list the RaspBee. @manup, would it be possible to add it? See https://github.com/gadgetoid/Pinout.xyz#contributing.

Took a while, the RaspBee pin description is now online:

https://pinout.xyz/pinout/raspbee

Pirol62 commented 4 years ago

I have really struggled the last day to get an 11 node network stable on my Pi 4 using a ConBee stick and deCONZ .66.

After including all nodes again, things looked OK, but not for long. I was now running my Pi 4 quite close to my WiFi router with the ConBee in one of the 2 USB2 slots on the Pi 4. After a while, all light-nodes became unreachable and unresponsive (remotes assigned to lights still worked OK, also switches and sensors). I picked up on the tip using an USB extension cord and used that (1.5m) for the ConBee. Things looked better, but after a few hours all green connections in the network diagram disappeared. All nodes unreachable. Since this looked like a stability issue and the Pi 4 is running very hot, I pulled out a powered USB2 HUB and attached the ConBee to that. Jury is still out, but 2 hours on it looks fine. Will report back with how it goes.

If anybody has any ideas what other things to check, please let me know.

Thanks for that tip @olemr . I faced the same issue but with RP3+. Always unavailable bulbs even I used an extension cable 1.5m. Ok, nothing to loose, I looked for an old USB hub and lucky me, I found an old, powerd, usb2.0 hub in my "electric waste". Plugged in 3 days ago and everything is fine since that time. Happy now :-)