Hi Dennis,
just curious about that, the coral already comes with an extension and i use that one already:
Does the lenght of the cable has any influence, because the coral cable is ca. 20 cm long?
cheers,
Philipp
Hi Philipp,
I really have no idea on that. It also could be related to shielding and such.
About your Pi: What casing is it in? Is it metal perhaps? Are you using WifI or bluetooth?
Hi Dennis,
it is this case, so yes, it is aluminium:
I am using an Ethernet-cable on the pi but i am not sure if Wifi is turned off. I will have a look in the config.txt later. Bluetooth is surely off. I bought a 3 m extionsion cable now and i am trying it with the Google Coral far away. I changed my Zigbee-Channel to 25 instead of 11 (it changed to 15 sometimes without doing something tho). If none of that works now i am out of ideas.
Maybe a plastic housing as the last approach but they are ugly af…^^ or you can make a good deal on a Conbee II and i put that on an extension cable.
Cheers,
Philipp
Hi Philipp,
I think that’s the issue here: The case. What happens if you take it out? Does it work then?
I am not employed by DE so i can’t do any “deals”. Neither do they do those as far as I know.
Kind regards,
Hi Dennis,
i saw now that the Zigbee-Channel switched from 25 to 11 again, i setted it again to 25 and edited the config.txt to disable wifi. After rebooting the raspbee cannot connect to the network anymore. In phoscon it shows firmware not connected.
I made a log file:
I reached the end of my knowledge. There is no device on the USB-Port at the moment and the Pi is without the case now. Is there a way to factory reset the raspbee and start from scratch?
I reverted the disable wifi in the config.txt after getting the error so for now there is only the default:
enable_uart=1
dtoverlay=pi3-miniuart-bt
followed by a blank line in the config.txt.
In the log i find the following:
New websocket 192.168.178.36:44600 (state: 3)
This is the IP of the wifi of the Raspberry and 192.168.178.35 is the Ethernet. Might it be that i crashed something today with the adding of the following to the config.txt:
dtoverlay=pi3-disable-wifi
It also states GW firmware version: 0x26520700 in the log, i am not sure but i remember something with 0x2666… was already on the GW.
And should that be audio? 
Cheers,
Philipp
Additional to the last logs i found an
API error 1, unauthorized user
and in the log below there is an
GW sd-card image version file does not exist: /data/.local/share/dresden-elektronik/deCONZ/gw-version
in the same log is also:
HTTP Server listen on address 0.0.0.0, port: 40850, root: /usr/share/deCONZ/webapp/
I think i lost you here.
at which point?
The one question that matters at the moment is, is there a way to factory reset the raspbee?
That is what i see at the moment.
Can you show me the network settings in deCONZ?
It would be easier to troubleshoot this on discord . Would you be able to join that?
Log from Repairing Process:
So i investigated the logs the last hours and saved at least 50K lines of log. As i am too lazy after that day to post 10 pastebin links, i just quote the most relevant issues here, the first two happen a lot at the beginning:
First one:
20:11:03:647 Device protocol version: 0x010E
20:11:03:728 send move to color temperature 400 to 0x0017880108524B20
20:11:03:729 drop request to zombie (rx = 0)
Second one:
20:19:29:866 APS-DATA.confirm id: 63, status: 0x00, match: 0
20:19:29:867 add task 2987 type 14 to 0x00178801088609E6 cluster 0x0006 req.id 113
20:19:29:868 failed to add task 2987 type: 14, too many tasks
20:19:29:869 API error 901, /lights/17/state/on, Internal error, 951
Then i get the following, but as we discussed earlier, that is because of a hard wired bulb which is not reachable at the moment:
20:13:04:219 Poll APS confirm 179 status: 0xE9
20:13:04:219 drop item state/colormode
20:13:04:220 0x001788010845EC35 error APSDE-DATA.confirm: 0xE9 on task
20:13:04:220 Erase task req-id: 179, type: 19 zcl seqno: 57 send time 1, profileId: 0x0104, clusterId: 0x0008
20:13:04:221 APS-DATA.confirm id: 179, status: 0xE9 MAC_NO_ACK
and the last one:
21:21:47:496 0x00178801083F3003 error APSDE-DATA.confirm: 0xAE on task
21:21:47:497 Erase task req-id: 116, type: 6 zcl seqno: 15 send time 2, profileId: 0x0104, clusterId: 0x0300
21:21:47:499 delay sending request 159 dt 1 ms to 0x00178801083F4B54, ep: 0x0B cluster: 0x0008 onAir: 1
21:21:47:500 delay sending request 159 ep: 0x0B cluster 0x0008 to 0x00178801083f4b54 onAir 1
21:21:47:501 APS-DATA.request id: 180, addrmode: 0x03, addr: 0x00178801083f3003, profile: 0x0104, cluster: 0x0006, ep: 0x01 -> 0x0B queue: 9 len: 3 tx.options 0x04
Thats it. So lucky me, not a single 0xE1, without the Coral. So, if the Raspbee is working while the Coral is on a long Extension Cable in the next run, that means i can keep my Aluminium Case or am i wrong?
Cheers and thanks a lot to the whole team for todays support,
Philipp
So even after 12 hours of a reconnected Coral USB Accelerator on an 3 m Extension Cable i have not encountered a single 0xE1 Error. I will reevaluate this over the next weeks to be absolutely sure it was only the coral that caused the interferences. If i get a single 0xE1 in the next weeks i change the Aluminium-case as well. I hope this issue can be considered as closed so far.
For everyone reading this thread, the solution to this whole situation was the following:
- unplugging the Google Coral as it caused 0xE1 Errors on the standard cable that gets shipped with it
- if you use Home Assistant, prepare a second SD-Card (consider using ConBee II SD-Karten Images or use Raspian but be sure to install deConz before trying to flash)
- manually updating and flashing of the firmware of the Raspbee as stated in the link below
- https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update-in-raspbian
- if the Flasher shows “retry, failed” ignore it and revert to Home Assistant, it worked despite of the message (should be fixed with the next GCFlasher version anyway).
- reinstalling and positioning of the Google Coral on a 3 m Extension Cable away from the Raspberry Pi
- repositioning of the Raspberry Pi to be more far away from a Sonos Arc just to be sure
Cheers,
Philipp
1 Like
Sounds promising. Note occasionally getting a 0xE1 error happens in most networks from time to time, it becomes only problematic if this happens very frequently.