Beaglebone Cape mit KNX & 4x Onewire; Enocean, RTC, eHZ möglich

[DarkSnoop]

Gibt es evtl ein aktuelles Image zum Download? Könnte Robert da was bereitstellen ? Gruß Darksnoop

[beckerth]

Gibt es schon eine Lösung für die Installation von enocean? Mit der Anleitung von Energiezwerg schaut die Installation machbar aus...

Grüße
Tommi

[daniel.duese]

Welches von Dir genutzte Plugin braucht pyserial?

sudo apt-get install python-pip
sudo pip install pyserial
sudo apt-get install python3-serial

danach konnte ich mit fhem wieder auf das enOcean Cape Modul zugreifen.

in der fhem.cfg den Eintrag

#### Enocean Server
define EnoceanServer TCM 310 /dev/ttyO4@57600

[Jürgen]

Hallo zusammen,

mein Kollege meint, mein Kernel unter Debian 10 wäre veraltet:

uname -a
Linux ibbgateway 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux

Also aktualisieren!

Zuerst die Quellen aktualisieren:

sudo nano /etc/apt/sources.list

Einträge überprüfen, wichtig ist hier der letzte Eintrag:

deb http://httpredir.debian.org/debian buster main
deb http://httpredir.debian.org/debian buster-updates main
deb http://security.debian.org buster/updates main
deb [arch=armhf] http://repos.rcn-ee.com/debian/ buster main

Speichern mit strg+o, dann strg+x verlassen

Mit den nächsten drei Befehlen wird der Kernel auf den letzten Stand für 4 gebracht, läuft auf den Debian Verstionen 8-10

cd /opt/scripts/tools/
git pull
sudo ./update_kernel.sh --lts-4_19

Danach rebooten
sudo reboot

Ergebnis:
Linux ibbgateway 4.19.50-ti-r20 #1buster SMP PREEMPT Fri Jun 21 19:38:44 UTC 2019 armv7l

Fertig!

Gruß Jürgen

[Energiezwerg]

Hallo Jürgen,
sieht nicht ganz aktuell aus.
Ich ja meinen Beagle Bone Black nach meiner Anleitung aufgesetzt und mich über Weihnachten mal wieder an updates getraut, macht man ja nicht sooo gern. Ganz normal über:

$ sudo update
$ sudo apt-get update

In dem Zuge wurde auch owserver, knxd, python ect. geupdated, also das, was für mich am wichtigsten ist. Seitdem läuft alles noch bestes.

$ cat /etc/debian_version
10.7
$ uname -a
Linux smarthome 4.14.108-ti-r107 #1 SMP PREEMPT Wed Jun 12 05:21:36 UTC 2019 armv7l GNU/Linux

Gruß
Andreas

[daniel.duese]

# cat /etc/debian_version
10.7
# uname -a
Linux ibbgateway 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

hab dieses Image genommen: bone-eMMC-flasher-debian-10.3-console-armhf-2020-04-09-2gb.img

[Jürgen]

Unfug, Lösung in #304

[Jürgen]

Upgrade auf Kernel 5.4

Hallo zusammen,

den Upgrade des V4 Kernels habe ich nun in #304 dokumentiert.

Nun ist für debian 10 ja auch ein Kernel 5.4 verfügbar, der laut Script Optionen auch installierbar ist:

Kernel Options:
ABI:1 LTS41 4.1.30-ti-r70
ABI:1 LTS44 4.4.155-ti-r155
ABI:1 LTS49 4.9.147-ti-r121
ABI:1 LTS414 4.14.108-ti-r108
ABI:1 LTS419 4.19.50-ti-r20
-----------------------------
Kernel version options:
-----------------------------
LTS414: --lts-4_14
LTS419: --lts-4_19
LTS54: --lts-5_4
LTS510: --lts-5_10
STABLE: --stable
TESTING: --testing
-----------------------------

Wenn ich bei mir das Kernelupgrade aus #304 starte, kommt nun aber eine Suche im "Jessie" Zweig, der bei 4.19 endet:

smarthome@ibbgateway:/opt/scripts/tools$ sudo ./update_kernel.sh --lts-5_10
info: checking archive
2021-01-09 12:50:29 URL:https://rcn-ee.com/repos/latest/jessie-armhf/LATEST-ti [168/168] -> "LATEST-ti" [1]

Vermutlich ist bei meinen Upgrades von Jessie über Stretch auf Buster noch irgendwie eine Umgebungsvariable, die auf Jessie zeigt, ich finde aber nichts :-(. Das ist dann auch der Grund, warum 4.19 bei mir nur bis 50 aktualisiert wird, die Version 94 gibt es nur im Buster Zweig)

War jemand schon Erfolgreich beim Upgrade auf 5.4? Hat jemand eine bessere Sources List bzw, ein besseres update_kernel.sh?
Oder besser: Einen Hinweis, an welcher Stelle sich mein BBB noch mit "Jessie" meldet?

Gruß Jürgen

[tobiasr]

Den 5.4er Kernel gibt es nicht mehr in Buster. Den musst du dir aus den Bullseye-backports laden. Diese dazu "normal" in der apt sources Datei hinzufügen. Und dann über apt -t bullseye-backports linux-kernel-5.xyz exakt den richtigen laden. Wie der aktuelle heißt, findest du über apt cache heraus.

[Jürgen]

Hallo Tobias,

doch, den gibt es, schau mal unter:
https://rcn-ee.com/repos/latest/buster-armhf/LATEST-ti


ABI:1 LTS41 4.1.30-ti-r70
ABI:1 LTS44 4.4.155-ti-r155
ABI:1 LTS49 4.9.147-ti-r121
ABI:1 LTS414 4.14.108-ti-r137
ABI:1 LTS419 4.19.94-ti-r57
ABI:1 LTS54 5.4.70-ti-r21

Mein Problem ist, dass das Script im Jessie Zweig einsteigt, nicht im Buster.
Daniel mit seinem 4.19.94 sollte das 5.4 problemlos installieren können...

NACHTRAG: Mit dem so geladenen Kernel startet der KNX Service nicht mehr :-( - Restore der 4.4 ;-(

Gruß Jürgen

[tobiasr]

Und warum zwingst du dein System nicht zur Installation von genau dem Paket per Hand? apt install linux-kernel-5.4.70-ti-r21 ? ggf. heißt das installations Paket etwas anders.

[Jürgen]

Hallo zusammen,

ist jemand von den BBB Cape User mit Debian 10 / Buster so freunlich, einmal den Inhalt von

cat /etc/apt/sources.list

zu posten? Die Zeilen ohne # davor reichen :-)
Gerne auch mit der Version des aktuell installierten Kernels.

Vielen Dank!
Jürgen

[DarkSnoop]

Hallo zusammen,

ist jemand von den BBB Cape User mit Debian 10 / Buster so freunlich, einmal den Inhalt von

cat /etc/apt/sources.list

zu posten? Die Zeilen ohne # davor reichen :-)
Gerne auch mit der Version des aktuell installierten Kernels.

Vielen Dank!
Jürgen

So soieht es bei mir aus.....

Kernel

Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux




deb http://deb.debian.org/debian buster main contrib non-free
#deb-src http://deb.debian.org/debian buster main contrib non-free

deb http://deb.debian.org/debian buster-updates main contrib non-free
#deb-src http://deb.debian.org/debian buster-updates main contrib non-free

deb http://deb.debian.org/debian-security buster/updates main contrib non-free
#deb-src http://deb.debian.org/debian-security buster/updates main contrib non-free


#Kernel source (repos.rcn-ee.com) : https://github.com/RobertCNelson/linux-stable-rcn-ee
#
#git clone https://github.com/RobertCNelson/linux-stable-rcn-ee
#cd ./linux-stable-rcn-ee
#git checkout `uname -r` -b tmp
#
deb [arch=armhf] http://repos.rcn-ee.com/debian/ buster main
#deb-src [arch=armhf] http://repos.rcn-ee.com/debian/ buster main

[GHild]

Hallo,

irgendwie verhält sich das OneWire System auf meinem BBB mit IBB Cape etwas merkwürdig.
Mein Setup ist up to date:

• Linux bbb 4.19.94-ti-r41 #1buster SMP PREEMPT Sat Mar 21 03:13:40 UTC 2020 armv7l GNU/Linux
• OneWire 3.2p3
• SmarthomeNG 1.8.2
• smartVISU 2.9

und funktioniert sonst stabil.

Seit dem dem Update auf smarthomeNG 1.8 werden allerdings nicht mehr alle Temperaturwerte der OW Sensoren in smarthomeNG übernommen. Ich bekomme die Warnungen:

2021-03-01 18:32:40 WARNING plugins.onewire 1-Wire: problem reading 28.BA7379A20103 /bus.0/28.BA7379A20103/temperature: no payload for /uncached/bus.0/28.BA7379A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:40 WARNING plugins.onewire 1-Wire: problem reading 28.788D79A20103 /bus.0/28.788D79A20103/temperature: no payload for /uncached/bus.0/28.788D79A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:40 WARNING plugins.onewire 1-Wire: problem reading 28.2B7879A20103 /bus.0/28.2B7879A20103/temperature: no payload for /uncached/bus.0/28.2B7879A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:40 WARNING plugins.onewire 1-Wire: problem reading 28.B0DE79A20103 /bus.0/28.B0DE79A20103/temperature: no payload for /uncached/bus.0/28.B0DE79A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:40 WARNING plugins.onewire 1-Wire: problem reading 28.1F9379A20103 /bus.0/28.1F9379A20103/temperature: no payload for /uncached/bus.0/28.1F9379A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:41 WARNING plugins.onewire 1-Wire: problem reading 28.C16C79A20103 /bus.0/28.C16C79A20103/temperature: no payload for /uncached/bus.0/28.C16C79A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:41 WARNING plugins.onewire 1-Wire: problem reading 28.DBB779A20103 /bus.0/28.DBB779A20103/temperature: no payload for /uncached/bus.0/28.DBB779A20103/temperature. Trying to continue with next sensor
2021-03-01 18:32:41 WARNING plugins.onewire 1-Wire: problem reading 28.D40479A20103 /bus.0/28.D40479A20103/temperature: no payload for /uncached/bus.0/28.D40479A20103/temperature. Trying to continue with next sensor

Mit smarthomeNG V1.7 habe ich diese Warnungen auch erhalten, aber die Werte waren dennoch verfügbar.

Nun bin ich mir nicht sicher, ob das ein Problem mit smarthomeNG ist oder mit dem OW System auf dem BBB.


Ich betreibe 2 OW Busse, einen parasitär, einen nicht-parasitär.
Im Moment ist BUS.0 der nicht-parasitäre und BUS.1 der parasitäre. Die Sensoren, die in smarthomeNG nicht gefunden werden, hängen an BUS.0.
bbb_ow_small.jpg

Hier ist die Übersicht im Browser:



Die Sensoren mit *70000 sind die parasitär angeschlossenen.
Was ich beobachtet habe:
- Die Sensoren, die physisch an BUS.0 hängen (aktuell *0103), tauchen manchmal doppelt in der Liste auf.
- In der Liste hängen sie alle unter BUS.0.
- Es gibt einen BUS.0 unter BUS.0
- Wenn ich die Sensoren selektiere, sehe ich vernünftige Messwerte
- Wenn ich die Stecker auf der Platine austausche, d.h. parasitäre als BUS.0 und nicht-parasitäre unter BUS.1, dann tauchen die nicht-parasitären doppelt im Browser auf und in der Fehlermeldung in smarthomeNG. Das deutet für mich darauf hin, dass etwas mit BUS.0 anders läuft als mit den anderen BUSsen.
- Wenn ich physisch unter BUS.1 und BUS.2 anschließe, werden gar keine Sensoren angezeigt (bis auf den einen on-board)

Was ich frage:

1. Stimmt etwas in der OW-Konfiguration nicht?
2. Habe ich ein Hardware-Problem mit den OW-Anschlüssen?
3. Läuft alles gut auf dem BBB und das Problem liegt rein bei smarthomeNG 1.8?

Vielen Dank für Hinweis.

Hier noch die owfs.conf:

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = 127.0.0.1:4304
#
# ...and owserver uses the real hardware, by default fake devices
# This part must be changed on real installation
#server: FAKE = DS18S20,DS2405
server: i2c = dev/i2c-2:0
server: i2c = dev/i2c-3:0
server: i2c = dev/i2c-4:0
server: i2c = dev/i2c-5.0
#
# USB device: DS9490
#server: usb = all
#
# Serial port: DS9097
#server: device = /dev/ttyS1
#
# owserver tcp address
#server: server = 192.168.10.1:3131
#
# random simulated device
#server: FAKE = DS18S20,DS2405
#
######################### OWFS ##########################
#
mountpoint = /mnt/1wire
allow_other
#
####################### OWHTTPD #########################
http: port = 2121
####################### OWFTPD ##########################
ftp: port = 2120
####################### OWSERVER ########################
server: port = 127.0.0.1:4304

[Jürgen]

Hallo noname..

Hmm, diese Meldung kenne ich weder unter 1.7, noch unter 1.8
Ich habe meine 16 Sensoren auf vier Linienverteilt alle parasitär in Betrieb. Versuche doch mal umzustellen.

Gruß
Jürgen