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

[GHild]

Hallo,

ich habe Roberts neues Image installiert und habe ein merkwürdiges Problem mit dem Enocean plugin.

Bei einem Neustart des Rechners kann Enocean nicht initialisiert werden. Im log-file finde ich den Errno 13:

2017-08-11  19:57:23 WARNING  Main         --------------------   Init SmartHomeNG 1.3.d250d91.dev   --------------------
2017-08-11  19:57:23 INFO     Main         Init Scheduler
2017-08-11  19:57:23 INFO     Main         Init Plugins
2017-08-11  19:57:24 WARNING  Main         CLI: You should set a password for this plugin.
2017-08-11  19:57:24 INFO     Main         enocean: Stick TX ID configured via plugin.conf to: ffbad000
2017-08-11  19:57:24 ERROR    Main         Plugin enocean exception: could not open port /dev/ttyS4: [Errno 13] Keine Berechtigung: '/dev/ttyS4'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 275, in open
    self.fd = os.open(self.portstr, os.O_RDWR|os.O_NOCTTY|os.O_NONBLOCK)
PermissionError: [Errno 13] Keine Berechtigung: '/dev/ttyS4'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/smarthome/lib/plugin.py", line 90, in __init__
    plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance)
  File "/usr/local/smarthome/lib/plugin.py", line 144, in __init__
    exec("self.plugin.__init__(smarthome{0}{1})".format("," if len(arglist) else "", argstring))
  File "<string>", line 1, in <module>
  File "/usr/local/smarthome/plugins/enocean/__init__.py", line 125, in __init__
    self._tcm = serial.Serial(serialport, 57600, timeout=0.5)
  File "/usr/lib/python3/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 278, in open
    raise SerialException("could not open port %s: %s" % (self._port, msg))
serial.serialutil.SerialException: could not open port /dev/ttyS4: [Errno 13] Keine Berechtigung: '/dev/ttyS4'

Wenn ich dann smarthome neu starte:

sudo systemctl restart smarthome

läuft es sauber durch:

2017-08-11  21:10:18 WARNING  Main         --------------------   Init SmartHomeNG 1.3.d250d91.dev   --------------------
2017-08-11  21:10:18 INFO     Main         Init Scheduler
2017-08-11  21:10:18 INFO     Main         Init Plugins
2017-08-11  21:10:18 WARNING  Main         CLI: You should set a password for this plugin.
2017-08-11  21:10:18 INFO     Main         enocean: Stick TX ID configured via plugin.conf to: ffbad000
2017-08-11  21:10:18 INFO     Main         enocean: eep-parser instantiated
2017-08-11  21:10:18 INFO     Main         Init Items
2017-08-11  21:10:18 INFO     Main         Items: 49
2017-08-11  21:10:18 INFO     Main         Start Logics

und meine Enocean- Geräte werden gefunden.

Das Problem müssten doch alle mit dem Image haben.
Habt ihr Hinweise, wo ich hinschauen muss ... oder noch besser wie ich das Problem beheben kann?

Danke
Gerd

[ugobald]

Hallo Jürgen,

man soll eigentlich eine Alias-Datei anlegen können, die dann von OW verwendet wird.
Funktioniert nur leider nicht so:

http://owfs.org/index.php?page=aliases
http://owfs.org/index.php?page=alias-improved

Haut das bei dir hin?

Gruß
Andreas

[Jürgen]

Hallo Andreas,

ist auch mein Stand, im Browser eintragen, nach Reboot weg. Dafür habe ich halt eine Excel Liste :-()
Geht es auch anders?

Gruß Jürgen

[ugobald]

Hi Leute!

Sagt mal, wie bekommt ihr das mit den 1-Wire Alias mit OW hin?
Ich habe in der /etc/owfs.conf folgenden Eintrag:

http: port = 2121
alias = /opt/ow-alias

Meine Datei /opt/ow-alias sieht folgendermaßen aus:

011B086919000067=REED_E2_Ost
011DBEEE180000F2=REED_E3_Sued_links
015804691900006A=REED_E1_West
019A4AF018000009=REED_E4_Sued_links
01ADBCEF180000F9=REED_E3_Sued_rechts
01BBD4DB18000079=REED_E5_Sued_rechts
01C3CD681900007D=REED_E5_Ost
01CD4DEF18000051=REED_E4_Sued_rechts
01E5BAEF180000B1=REED_E5_Sued_links
28FF973760140473=Temp_IBB

Über owhttpd bekomme ich die Aliase aber einfach nicht angezeigt, sondern nur die ID. Ich kann ein Alias zwar manuell zuteilen, das ist nach dem nächsten Neustart aber auch wieder gelöscht. Damit tu ich jetzt schon wieder stundenlang rum...

Danke und Gruß
Andreas

[ugobald]

Hallo!

Einige Erkenntnisse von heute:

1. Der interne Temperaturfühler vom BB hängt am Bus.0. Wenn irgendwas den Bus stört, werden keine Sensoren mehr angezeigt. Darum ist der interne Sensor immer verschwunden. Man kann den Sensor jetzt gut als Indikator für Fehler am Bus nutzen. Ist er da: Alles OK; Verschwindet er: Es gibt ein Problem.
2. Am Klemmenblock war eine Brücke falsch gesetzt.
3. Hänge einen DS18B20 nie mit allen drei Pins an GND, DATA und VDD, er könnte sehr heiß werden (Wäre dafür der Pull up-Widerstand da?)
4. Ich habe anscheinend noch ein Problem mit den Leitungen.
   1. 1-Wire ist als offener Ring verlegt. Jetzt habe ich vom BB aus angefangen, jede Klemmstelle zu öffnen und den Ring somit zu unterbrechen um dann zu schauen, ob der BB-Sensor angezeigt wird. So lässt sich die Linie Stück für Stück auf Fehler prüfen.
   2. Beim ersten Durchlauf bin ich recht weit gekommen, bis ich nicht mehr wusste, wie die Leitungsführung weitergeht.
   3. Beim zweiten Durchlauf habe ich nur knapp die Hälfte geschafft und ab einer bestimmten Klemmstelle hat es nicht mehr funktioniert. Wobei es beim ersten Durchlauf noch funktioniert hat?!

Ich weiß leider schon wieder nicht mehr weiter. Die Adern sehen alle gut aus, soweit man das in der Dose beurteilen kann. Auch die Spannung von 5 V bleibt konstant.
Hättet ihr mir Tipps, wie ich da einem Fehler weiter auf die Spur kommen könnte?

Besten Dank!
Andreas

[ugobald]

Hallo Jürgen,

kann man so festhalten!

Ich hatte vorher ja die gesamte fertig verlegte Linie mit zwei Sensoren (REED-Platine und DS18B20) am BB angeklemmt. Nachdem der Fehler dort aufgetreten ist, wollte ich ein Leitungsproblem ausschließen, indem ich die Klemmstellen und Leitungslänge drastisch reduziere: Anklemmen von nur einem Meter Leitung mit einem Temperatur-Sensor. Gleiches Problem.

Das wäre jetzt das Äquivalent zu meinem Testaufbau: Kurze Leitung mit Sensor an BB. Dort hatte es funktioniert und die Sensoren wurden immer sofort erkannt.

Um deine Antennentheorie zu prüfen, wieviele Sensoren sollten denn dafür hin? Wobei ich mir es nicht so Recht vorstellen kann, der OWServer sollte doch unabhängig von so etwas sein und hat trotzdem ein Startproblem.

Gruß
Andreas

[Jürgen]

Hallo Andreas,

ja, der Service von Robert ist top!
Deinen Ansatz versthe ich aber nicht...
Du klemmst viele Meter Leitung ohne Sensor an und wunderst Dich über einen Fehler?
Über diese "Antenne" ohne Leitungsabschluss kommt alles Mögliche auf dein Cape.
Bau mal eine vernünftige Linie mit 1-Wire Sensor auf und teste dann.

Gruß Jürgen

[ugobald]

Sodale, erst mal vielen Dank an Robert für das unbürokratische Reparieren meines IBB Capes!
KNX über knxd funktioniert wieder einwandfrei nur mit 1-Wire kämpfe ich gerade ein bisschen. Ich weiß aber so langsam nicht mehr, wo ich suchen soll und ob es am Cape selbst oder nem Fehler auf meiner Seite liegt.

Fehlerbild: Solange nichts an den vier Bus-Ports eingesteckt ist, funktioniert es gut und sieht so aus:

bus_listing_vorher.JPG

Der 28.xxxx ist der Platinensensor.

owserver_status_vorher.JPG

Sobald ich jetzt meine EG-Linie einstöpsle, verschwindet der Platinensensor aus dem Bus-Listing und nach einem Neustart des Beaglebones startet auch der OWServer nicht mehr:

bus_listing_nachher.JPG

owserver_status_nachher.JPG

Es hängt allerdings noch kein Sensor oder Verbraucher am 1-Wire-Bus. Einen Verkabelungsfehler konnte ich beim Drüberschauen auch ausschließen. Beim Messen mit dem Multimeter sind sowohl bei VDD als auch bei DATA 5 V drauf und zwar an jeder Klemmstelle.

Um einen Fehler im Bus-Netz auszuschließen, habe ich einen halben Meter grüne Leitung direkt an den Bus-Port vom IBB-Cape gehängt. Jetzt funktioniert wieder alles. Hänge ich jetzt noch einen DS18B20 Fühler an die grüne Leitung, bekomme ich wieder das selbe Fehlerbild von oben. Heißt: Ohne Verbraucher = funktioniert; mit Verbraucher direkt und ohne Umweg angehängt = funktioniert nicht.

Der Test mit einem anderen DS18B20 hat auch nichts verändert und ich kann mir nicht vorstellen, dass beide defekt sind. Gepolt sollten sie auch richtig gewesen sein, angeschlossen wurde laut Datenblatt.

Ich habe das aktuellste Image von Robert installiert (https://ing-budde.de/?page_id=171) und meine owfs.conf sieht so aus:

# Sample configuration file for the OWFS suite for Debian GNU/Linux.
#
#
# This is the main OWFS configuration file. You should read the
# owfs.conf(5) manual page in order to understand the options listed
# here.

######################## SOURCES ########################
#
# With this setup, any client (but owserver) uses owserver on the
# local machine...
!server: server = 192.168.178.42: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=ALL: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 = 192.168.178.42:4304
# server: device = /dev/ttyS1
# server: server = localhost:4304

Hat jemand ne Idee, was da sein könnte oder was ich testen kann?
Da war ich jetzt wieder den ganzen Tag dran gesessen und bin schon wieder kurz vorm Verzweifeln.

Vielen Dank schonmal!
Andreas

[Robert]

Hallo Andreas,

die Pins sollten auf der bereits geposteten Webseite ersichtlich sein: elinux.org/BeagleBone_Community

Bei Versorgung mit 5V bzw. 3,3V sollte jeweils ein Strom von 100mA nicht überschritten werden. Dann kann (relativ) gefahrlos ein neues Beaglebone angeschlossen und gestartet werden ohne eine Beschädigung dessen zu riskieren. Anschließend kann man mit einem Image prüfen was noch auf dem Cape funktioniert.

Gebraucht wird also mindestens ein einstellbares Labornetzteil mit Strombegrenzung (auf eben z.B. 100mA).

Wahrscheinlich ist es einfacher wenn ich es kurz teste. Weiteres per PN.

Grüße
Robert

[ugobald]

Hallo Robert,

danke für deine Hilfe!
Wenn es "nur" beim Beaglebone bleibt, das wär ja schon was.
Den BUS.2 vom Cape kann ich aber sicherlich abschreiben. Nur wenn 1-Wire komplett nicht mehr funktioniert, sieht es allerdings schlecht aus mit der Verwendung in meiner Installation...

Könnte es den neuen Beaglebone gleich zerschießen, wenn ich das mit der Stromaufnahme vorher nicht ordentlich teste? Weil mir fehlt es am Labornetzteil und möglicherweise an den E-Technik-Kenntnissen. Aber wenn ich so ein Netzteil auftreibe:

1. Wo müsste ich das Netzteil am Cape anklemmen? Die Spannungsversorgung geschieht ja normalerweise über den Beaglebone.
2. Als Spannung dann 5 V Spannung am Netzteil einstellen?
3. Und geh ich ich dann einfach mit nem Multimeter an die entsprechenden Pin-Paare?
4. Was muss als Ergebnis ankommen? 3,3 V und 5 V?

Vielen Dank!
Andreas

[Robert]

Hallo!

Das sieht leider, soweit aus der Ferne zu beurteilen, nicht gut aus.

Das Beaglebone wird es wohl - wenn nicht mal mehr einzeln zu betreiben - dahingerafft haben. Hier hilft nur ein Neues.

Beim Cape sollte zur Sicherheit vor Anschluß an ein neues Beaglebone die Stromaufnahme der 3,3V und 5V Versorgung gemessen werden. Das geht am einfachsten indem die entsprechenden Pins (elinux.org/BeagleBone_Community) P8-1 und P8-3 (3,3V) und P8-1 und P8-5 (5V) mit einem entsprechenden Labornetzteil mit Strombegrenzung getestet werden. Tendeziell stehen die Chancen gut, dass KNX- und Enocean-Interface überlebt haben. Auch für den restlichen Onewire-Teil würde ich nicht pauschal von Exitus ausgehen.

Grüße
Robert

[ugobald]

Hallo zusammen,

Genervtheit und an seiner Installation rumbasteln rächt sich. Bei einer Fehlersuche am KNX-Netz habe ich gestern in völliger Blödheit die 30 V KNX-Spannung am 1-Wire-Eingang vom IBB Cape angelegt. Nachdem sich der Gestank verzogen hat, blieb mir nur mehr ein nicht funktionierendes knxd-Interface übrig.

Mit dem Auge lässt sich nur erkennen, dass der SMD-Chip am BUS.2 aufgebläht ist und wohl die Grätsche gemacht hat. Die Bauteile in Reihe davon sind wohl auch betroffen.

dsc_0008ksfj0i.jpg

Ich bekomme aber weder den Beaglebone alleine (mit und ohne SD-Karte) noch mit IBB Cape nicht mehr zum Laufen, heißt: Bei einer Direktverbindung mit Bildschirm, bootet nichts mehr.

Ist da noch irgendwas zu retten? :-/

Danke und Gruß
Andreas

[shakalandy]

Hat jemand mal Home Assistant (home-assistant.io) probiert?
Bekomme hier irgendwie OneWire nicht zum Laufen über das IBB Cape, da wenn ich es richtig verstanden habe die OneWire Sensoren in einer VerzeichnisStruktur erwartet wird. Konfiguriere ich diese im BB in der /etc/owfs.conf, beispielswiese als /mnt/onewire, so bleibt das Verzeichnis leer und wir nicht mit den Sensoren gefüllt, die ich über den OWFS Browser abrufen kann.
Hat einer ne Idee oder das schon mal getestet?
home-assistant.io/components/sensor.onewire/

Vielen Dank!

[hotzen]

Hast du eine Empfehlung wie man einfach images upgradet? wie/wohin speicherst du denn die dutzenden Konfiguration Einstellungen hin, die so zusammenkommen?

Bin das erste mal am überlegen ernsthaft nicht zu Upgraden. Insbesondere weil ich knxd und smarthome.py von Hand immer hochziehe

Danke!

[Robert]

Da einige Nachfragen wegen des knxd aufkamen und sich auch bei anderen Paketen Feinheiten verbessert haben, habe ich ein neues Image erstellt. Die Abbilder sind auch ohne IBBCape nutzbar und können leicht auf andere Schnittstellen-Hardware angepasst werden.

• Linux-Kernel 4.4.54-ti-r93
• Debian Jessie 8.7 rootfs
• knxd 0.12.15
• owserver 2.9p8
• smarthomeNG (smarthome.py Fork) stable
• smartVISU 2.8

Viel Spass!

Grüße
Robert