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

[chrispr74]

Capes wieder verfügbar ?

Hi,

es soll nicht als "drängeln" rüberkommen .. , aber es ist ja nun schon nach Weihnachten.

Sind Capes schon wieder verfügbar oder wirds noch etwas dauern ?

Es ist das einzige welches mit KNX, eHZ und 1-Wire in einem zur Verfügung stellen kann.



Danke

Grütze

ChrisPr

[schloessl]

Hallo Robert,

einmal eine kleine Entwarnung!

Ich habe neu aufgesetzt mit
BBB-eMMC-Flasher-debian-7.7-lxde-4gb-armhf-2014-12-11-4gb.img.xz

Ich arbeite ich mitdem

Beaglebone Black Rev C (Element14)
Der BeagleBone Black 4G ist das neuste Mitglied in der BeagleBoard-Familie, welches mit einem Sitara AM3358 ARM Cortex-A8 von Texas Instruments angetrieben wird. Der BeagleBone Black wird mit vorinstalliertem Linux Debian ausgeliefert und richtet sich nicht wie seine Vorgänger hauptsächlich an Entwickler, sondern auch an Bastler und Studenten.
Beagleboard:BeagleBoneBlack Debian - eLinux.org

Betriebsspannung 5 V/DC
Gewicht 40 g
Arbeitsspeicher
512 MB
Prozessor TI Sitara™ AM3358 ARM Cortex™-A8 1GHz
Flash-Speicher 4 GB eMMC
Speichertyp DDR3L-RAM


laut rcn-ee und google gab es für wenige Stunden auch ein jessie, war dann aber wieder verschwunden.

laut Google : v3.14.26-ti-r42

mal Wheezy
Index of /deb/wheezy-armhf - rcn-ee.net
https://rcn-ee.net/deb/wheezy-armhf/Diese Seite übersetzen
... 16:55 - v3.14.26-ti-r41/ 15-Dec-2014 12:20 - v3.14.26-ti-r42/ 19-Dec-2014 17:44 - v3.14.26-ti-r43/ 23-Dec-2014 16:13 - v3.14.26-ti-r44/ 09-Jan-2015 19:24 ...
mal Jessie
Index of /deb/jessie-armhf - rcn-ee.net
https://rcn-ee.net/deb/jessie-armhf/Diese Seite übersetzen
... 13:58 - v3.14.26-ti-r41/ 15-Dec-2014 09:20 - v3.14.26-ti-r42/ 19-Dec-2014 12:30 - v3.14.26-ti-r43/ 23-Dec-2014 12:36 - v3.14.26-ti-r44/ 09-Jan-2015 15:46 ...


Mit dieser Version laufen jetzt schon einmal eibd und owfs problemlos.

Hier ergeben sich für den "Debian-Anfänger" einige Fragen.

1) Gibt es für die unterschiedlichen BBB herstellerabhängige Kernels und der der Rest ist klassisch Debian.

Hintergrund: bei der Erstinst. lief eibd und owfs sofort problemlos. Beim ersten apt-get update zu Beginn der smarthome-Vorbereitung war alles wieder vorbei.

2) zu Deinem letzten Post, kann ich jetzt ein "jessie-testing" über die stehende Wheezy bügeln!
( Bei einer "wheezy"-Installation könnte man sich jetzt daher sinnigerweise aus eben "testing/jessie" bedienen

Ich habe jetzt alle Sensoren sichtbar, das Programm läuft stabil.

Leider kämpfe ich noch mit easy_install3 pip und ephem.
Reading state information... Done
E: Unable to locate package easy_install3
E: Unable to locate package pip

Also, noch einmal Danke für Deine Tipps und Hilfen.
Ich hoffe den Rest schaffe ich auch noch!

Wolfgang

PS Gibt es irgendwo ein BBB-Jessie-IMG?

[Robert]

Hi Marco,

ja, als Basis habe ich zuletzt das aktuelle/kommende Jessie genommen. Das bald "alte" Wheezy funktioniert aber prinzipiell genauso und wurde zu Anfang von mir auch vorgeschlagen. Wie "stable/testing/unstable" sich auf "wheezy/jessie/sid" mappen steht hier: https://www.debian.org/releases/

Ich wundere mich daher warum das nicht reibungslos funktioniert. Evtl. könnte das hinzufügen des "unstable" branches unter 4.1 das Problem verursachen. Mittlerweile ist aber auch owfs in Jessie auf 2.9p8-6 aktualisiert worden (https://packages.debian.org/jessie/owserver), daher braucht man unter Jessie eben sich nicht mehr aus "unstable/sid" bedienen (noch ein Grund für Jessie). Bei einer "wheezy"-Installation könnte man sich jetzt daher sinnigerweise aus eben "testing/jessie" bedienen:

„echo "deb http://ftp.debian.org/debian [B][COLOR=Red]testing[/COLOR][/B] main" >> /etc/apt/sources.list“

Davon ab: Dein eibd-Autostart funktioniert wohl noch nicht: Die Anleitung sollte da völlig unabhängig von wheezy/jessie sein:
Wo hakt es? Anleitung Punkt 3.3!

• "eibd"-Datei kopiert?
• Ausführbar gesetzt?
• update-rc.d aufgerufen?

Grüße
Robert

[schloessl]

BeagleboneBlack

Korrekt und auch so in der Anleitung beschrieben SV/sh.py. Denn bevor ich eine neue Anleitung rausgebe schreibe ich eine sd-Karte komplett mit dem unter (1) genannten Basisimage und hack dann die 20 Befehle kurz selber rein.

Grüße
Robert

So steht es in meinem Textfile:

root@smartgate:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"

Hallo Robert,

danke für Deine Antwort. Den ganzen Samstag habe ich noch gekämpft, leider ohne Erfolg.

Beim finalen dokumentieren meiner Schritte ging mir ein Licht auf!

Du arbeitest mit Jessie, wie es natürlich in der Anleitung steht!!

Das war es dann, irgendwo bei dei Installation nach Beschreibung kamen Texte wie " Version ist seit 65 Tagen obsolet..."
Irgenwie ist mir da wohl ein Wheezy rein gerutscht!

PS. Wird es einmal ein "Wheezy" geben.

Ich habe soeben einen Beitrag gefunden in dem Du Wheezy erläuterst. ziehe deshalb die Frage zurück!
Warum 2 wiedersprechende Anleitungen? Wo liegen die Probleme/ Vorteile?

Wolfgang

[Robert]

Korrekt und auch so in der Anleitung beschrieben (4.2) ist als Quelle

server: i2c = dev/i2c-2:0
server: i2c = dev/i2c-3:0
server: i2c = dev/i2c-4:0
server: i2c = dev/i2c-5:0

sonst unter Sources nichts. Es sind keine weiteren Änderungen nötig (und auch nicht in der Anleitung gefordert!). Wenn der Test über den Browser "ip-des-bbb:2121" funktioniert (wie in der Anleitung 4.3 beschrieben), dann goto smartVISU/smarthome.py.

Gleiches für den eibd. Anleitung 3.3 befolgen, dann funktioniert der Autostart. Danach: goto smartVISU/smarthome.py.

Den Rest habe ich leider nicht verstanden.

Bei älteren Versionen der Anleitung genauso: wenn man exakt das macht was da steht erhält man immer! einen funktionierenden Unterbau für SV/sh.py. Denn bevor ich eine neue Anleitung rausgebe schreibe ich eine sd-Karte komplett mit dem unter (1) genannten Basisimage und hack dann die 20 Befehle kurz selber rein.

Grüße
Robert

[dschwert]

Schau immer auch auf die Überschriften: da steht ### SOURCES ###

server: server = .... ist demnach für den Zugriff vom OWSERVER auf den 1-Wire-Bus. Wenn du einen lokalen Busmaster hast, ist das sicher falsch.
server: server = 192.168.115.35:3131 stimmt daher auch eher nicht.

Ob server:i2c ... stimmt weiß ich nicht. Bei einem Raspberry mit ROT lautet die Zeile z.B.
server: device= /dev/i2c-1
Bei einem USB-Busmaster:
server: usb = all

Erst ganz unten unter #### OWSERVER #### gibt server: port = 4304 an, auf welchem Port der Server seine Dienste anbietet.

Gruß,

Dietmar

[schloessl]

1-Wire , owserver, owhhtpd auf BBB Probleme

Hallo,

ich hänge mich einmal hier hinein, da ich kein sinnvolles Posting gefunden habe.

Ich hatte das IBB-Cape gekauft und mir der beiliegenden Anleitung begonnen.
Sofort wurden die 1Wire-Sensoren des Capes angezeigt.

Bei der weiteren Installation ging bei einem Update die Debianversoin auf
"nicht weiter supported", so ähnlich in englisch.
Gleichzeitig fand ich eine neuere Installationsanleitung von Robert für wheezy.

Hier hänge ich!!
Eibd läuft bei manuellem Start. Knx.Signale werden angezeigt.
owserver und owhttpd waren fehlerfrei zu starten, jedoch kein Zugriff über smartware.
ows.conf verändert. Jedoch kein Erfölg. Debian usw. leider eine totale Fremdsprache für mich!!
In beiliegendem Textfile habe ich einmal den Stand dokumentiert.
Derzeit ist nur eidd und owfs installiert. Ich vermute eine falsche Zuordnung der IP-Adressen. Ist der server localhost oder meine IP?

Bitte wer schaut einmal über das Textfile und kann mir einen Tipp geben
Welche Dateien/Protokolle werden noch benötigt?

Danke!

LG
Wolfgang

[Robert]

Da ich jetzt leider ein paar Leute vertrösten musste: Momentan sind leider die Capes "aus". Nach Weihnachten sollte ich wieder welche da haben und werde das dann hier kund tun.

Viele Grüße
Robert

[Robert]

Die dritte Generation ist fertig!

Hallo Beaglebone-Fans!

Einige Anfragen und die Begeisterung für die Phoenix Contact PTSM-Steckverbinder (siehe https://knx-user-forum.de/diy-do-you...chtigkeit.html, letzte Revision von mir) haben mich dazu verleitet noch mal eine neue Version des IBB Capes aufzulegen.

Damit ich selber Mengestaffelungen nutzen konnte habe ich ein paar Capes mehr gelötet.

Alle Features der zweiten Version wurden beibehalten, zudem ganz es kleinere Verfeinerungen:
- Phoenix Contact PTSM Steckverbinder für den Onewire: für Massive Adern und Litzen (Litzen können auch ohne Probleme wieder entfernt werden), Steckbare Verbindung (siehe Photos), eindeutige Codierung (Verpolungsschutz), Beim Umverdrahten etc können lose Stecker generell im Schrank baumeln, keine unisolierten Litzenenden.
- erweiterte Schutzbeschaltung der seriellen Schnittstelle: zusätzlich zu Reihenwiderstand und Schottkydioden sind alle Kontakte mit Induktivitäten geschützt (ich hatte sonst ganz selten Störungen weil mein Auslesekabel quer durch den Schaltschrank muss).

Die Version ohne Enocean ist entfallen, da ich eine Pasten-Maske "mit Enocean" hatte und ein Nachbestücken nicht sinnvoll ist. Für schlanke 25 Euro Mehrkosten bekommt man so ein Enocean Interface mit professioneller SMA-Buchse für externe Antennen (wichtig im Schaltschrankeinbau, vgl. USB 300 oder die Raspberry-Platine). Die RTC habe ich nicht mehr bestückt, da ich von keinem wüsste der sie je benützt hätte.

Durch Enocean-Modul, SMA-Stecker und die lösbaren PTSM-Stecker/Buchsen setze ich diesmal einen Stückpreis von 109 Euro zzgl. Versand an.

Funktion: Beaglebone-Cape mit 4x Onewire Busmaster (owfs >2.9), KNX-Interface basierend auf TPUARTv2 (eibd), Enocean-Interface mit SMA-Verbinder basierend auf TCM300/TCM310 (identisch zu USB 300 Dongle und kompatibel zu OpenHAB, FHEM und smarthome.py), serielles Interface mit Schutz-/Filterbeschaltung und RJ11-Stecker zum Auslesen von eHZ

Lieferumfang: Cape, KNX-Klemme, PTSM-Stecker, RJ11-Stecker, Anleitung zur Installation von Linux und Test der Schnittstellen. Nicht enthalten sind eHZ-Auslesekopf und die Enocean-Antenne!

Schreibt mir bitte eine PN bei Interesse!

[wusaman]

Weiterempfehlung

Hallo,
ich habe eines der Capes aus der ersten Charge gekauft. Es ist voll bestückt mit allen Schnittstellen, allerdings nutze ich derzeit nur das KNX Interface. Eibd und das Kernel habe ich selbst kompiliert. Hast zwar etwas gedauert, aber es geht. Anschließend smarthome und smartVISU drauf installiert. Da ich faul bin, habe ich aus meinem IP-Symcon Server (den ich bald nicht mehr nutze), mein PHP Script mit den Hausadressen auf das Begale und mir ein kleines PHP Programm geschrieben, das mir die smarthome items und logic, sowie die HTML Seiten für smartVisu automatisch erstellt. Läuft alles prima, insbesondere läuft Roberts Cape bislang sehr stabil. Es ist sauber entflechtet und macht einen guten Eindruck. Ich kann es also mit drei Sternen *** sehr weiter empfehlen.
Grüße
Daniel

Nachtrag: Bei mir läuft Kernel 3.8.13-bone47

[chrissyheb]

Hallo Robert,
ich möchte auch ein Cape vorbestellen.
Bitte gib Bescheid, wenn wieder welche fertig sind.
Danke Chrissy

[Geles]

Hallo Robert,

bin auch an Deinem Cape interessiert. Falls Du diese wieder vorrätig hast, würde ich gerne auch eines beziehen.

Danke im voraus.

Michael

[ttrepper]

Momentan sind leider alle Capes verkauft. [...] Habe aber neue Platinen geordert.
Robert

Hallo Robert, wenn Deine neuen Platinen kommen und Du sie verkaufst hätte ich auch Interesse an einer.
Kannst mich gerne verbindlich vormerken.
Herzlichen Dank, Thomas

[2Fast4You78]

Hallo Robert.. Bei Dropbox einfach in den öffentlichen Ordner.. Kannst es mir auch schicken und ich stell es bereit


Gesendet von meinem iPad mit Tapatalk

[Robert]

So, hab heute mal den aktuellen Stand angeschaut:

Vorab bezüglich LCD-Cape:

Mit 3.8.13-bone43 aus dem aktuellen, offiziellen Debian-Image von Beagleboard.org funktioniert sowohl das 4,3" LCD https://knx-user-forum.de/diy-do-you...ontroller.html als auch (separat getestet) das manuelle Laden des IBB Capes. Ergo kann man dafür auch (auf dem Beaglebone selber) den modifizierten Kernel benutzen (Anleitung: "Build Kernel.docx"). Sind nur 7 Schritte und funktioniert zu 100%.

Update auf 3.13.8

Ausgangspunkt ist ein System mit 3.8.x und Internetzugang (z.B. das offzielle Image von BeagleBoard.org - latest-images mit allen Bells-and-Whistles):

• wget https://rcn-ee.net/deb/wheezy-armhf/.../install-me.sh
• chmod a+x install-me.sh
• ./install-me.sh
• reboot

Damit hat man einen neuen 3.13.8 Kernel. Leider ist der Support für den benutzten I2C-Switch PCA9546 nicht aktiviert, daher entweder selber den Kernel bauen (dank Rober C. Nelson wirklich einfach!) und in der Kernel-Config den PCA9546 mit einkompilieren oder von mir den Kernel mit aktivierten Treiber anfordern (weiß jemand wie ich zwei 6 MB Dateien irgendwo vernünftig und einfach anbieten kann?):

• 3.13.8-bone8.zImage auf das Beaglebone kopieren (WinSCP oder beim offiziellen Image auch per USB unter Windows direkt als Mass Storage Device)
• cp 3.13.8-bone8.zImage vmlinuz-3.13.8-bone8
• cp 3.13.8-bone8.zImage uboot/zImage

Dann nur noch den Device Tree aktualisieren. Auch hier wieder die Möglichkeit, von mir die fertigen *.dts zu bekommen und nur unter /boot/uboot/dtbs/ zu kopieren oder selber machen:

• git clone git://github.com/RobertCNelson/rscm.git
• cd rscm
• enable-ibb-cape.diff irgendwohin kopieren (z.B. ./3.13-bone/simple/) und
• patch -p1 < ./3.13-bone/simple/enable-ibb-cape.diff
• apt-get install device-tree-compiler
• ./build.sh
• reboot

Auf Basis eines laufenden 3.8.x Images ist das ganze bei der Kopier-Lösung innerhalb von 5 Minuten erledigt (Download des neuen Kernel dauert so lange). Wenn der 3.13.8-bone8 schon läuft dauerts vl. 30 Sekunden (4 Dateien ersetzen). Selber kompilieren kommt auf das Buildsystem an.

Für den 3.13.8 habe ich zudem die Taktfrequenz des i2c-2 testhalber auf 400 kHz hochgesetzt um den Zugriff auf die vier Onewire-Busmaster weiter zu beschleunigen. Dabei gehe ich davon aus, dass das IBB Cape das einzige Cape ist. Bei mehreren Capes sollte man sich im Problemfall evtl. mit 100 kHz begnügen.

Da der I2C-Multiplexer die Sub-Busse als /dev/i2c-1, /dev/i2c-3, /dev/i2c-4, /dev/i2c-5 erzeugt muss eine entsprechende owfs.conf verwendet werden, welche wirklich auch nur diese Busse selektiert. Dadurch konnte der Overhead für den I2C-Mux auf einen einzigen Zugriff je Busmastertransaktion reduziert werden (Hintergrund: sonst wäre ein deselect-on-exit notwendig, um nicht einen "Geister-Busmaster" auf /dev/i2c-2 zu erhalten).

Im Anhang: Patch für die Device Tree Dateien bzw. die fertigen Device Tree Dateien für Beaglebone (White) und Beaglebone Black (BBB) und eine angepasste owfs.conf. Mittlerweile habe ich Robert Nelson angemailt damit er bitte den PCA9546-Support wieder aktiviert. Dann muss nur noch eine einzige Datei auf einem 3.13.x System ersetzt werden.

Dasa Upgrade auf 3.13.8 macht für alle Sinn, die nur das IBB Cape verwenden und die maximale Leistung haben wollen. Viele Capes, so z.B. das oben erwähnte 4,3" LCD-Cape werden momentan nicht unterstützt.

Grüße
Robert