Wie wohnt euer Raspi? Wie habt ihr eure GPIO angeschlossen?

Begonnen von Marlen, 22 August 2017, 11:38:44

Vorheriges Thema - Nächstes Thema

Beta-User

Wie wäre es zur Abwechslung mal mit einem Blick ins Wiki und die Commandref ;) ?

Zu Arducounter (Du hast 3 Zähler an GPIO, wenn ich das richtig verstanden habe):
ZitatThe ArduCounter module works together with an arduino board connected to FHEM via usb that runs the provided ArduCounter.ino sketch to count impulses from energy meters with an S0 interface or similar devices in configurable intervals.
Zitat
define AC ArduCounter /dev/ttyUSB2
attr AC factor 1000
attr AC interval 60 300
attr AC pinD4 falling pullup
attr AC pinD5 falling pullup 30
attr AC pinD6 rising
this defines three counters connected to the pins D4, D5 and D5. D4 and D5 have their pullup resistors activated and the impulse draws the pins to zero. For D4 every falling edge of the signal (when the input changes from 1 to 0) is counted. For D5 the arduino measures the time in milliseconds between the falling edge and the rising edge. If this time is longer than the specified 30 milliseconds then the impulse is counted. If the time is shorter then this impulse is regarded as noise and added to a separate reject counter.
For pin D6 the ardiono counts every time when the signal changes from 0 to 1. The ArduCounter sketch which must be loaded on the Arduino implements this using pin change interrupts, so all avilable input pins can be used, not only the ones that support normal interrupts.
Finde ich nicht unbedingt kompliziert, man muß halt einmal einen Arduino flaschen (am einfachsten mit der Arduino-IDE). Einbinden dann besser "by-id" (Trick der Woche im Wiki), dazu am besten gleich nur Arduinos verwenden, die eindeutig zu identifizieren sind (nicht CH340, hier wäre ein China-FTDI-Nano für 4 Euro völlig ausreichend; leider gibt es da hin und wieder fakes).

MySensors ist etwas komplizierter, aber auch keine Raketentechnik. Als Gateway (hat eine ähnliche Funktion wie ein CUL&Co für HM) würde ich auch hier einen Arduino als serielles GW (=USB) empfehlen, wieder keinen CH340-basierten (der bereits für 2 Euro in China zu haben ist und den man für weitere Nodes gut nehmen kann).
Die Krux für MySensors und mehrere Counter am Arduinos ist die, das die Beispiele bei MySensors interrupt-basiert sind und der Nano nur 2 voll interrupt-fähige PINs hat; dann muß man andere PINs nehmen, die entprellen (also etwas mehr Logik in den Code reinstecken), aber: es geht auch...

Mein o.g. Beispiel sollte nur ein Hinweis darauf sein, dass Arduinos was sehr flexibles sind, die für firmata (weitere Arduino-basierte Option, mit der das vermutlich auch ginge, bitte selber mal SuFu bemühen) eigentlich viel zu schade sind.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Frank_Huber

Vom 4.9er Linux kernel abgesehen läuft das bei mir ganz stabil mit den gpio. Will aber dennoch vor dem pi noch optokoppler installieren.

Die ganzen Infos und Empfehlungen habe ich in meinem Fall erst gelesen als das Haus längst geplant und verkabelt war.

Wenn ein pi mal stirbt wegen gpio gibt's  eben nen neuen.

Und wenn es in 10 Jahren keinen pi mehr gibt dann gibt es sicherlich Nachfolger.

Ich mache mir bei der zukunftstauglichkeit keine Gedanken. Wer sagt denn auf der anderen Seite dass es in 10 Jahren noch hm, max u d b dergleichen gibt?
Und wenn alle IOs an gleicher Stelle verbaut sind kann ich auch irgendwann auf was ganz anderes umstellen. Selbst dumme 24v eltakos wären denkbar.

Gesendet von meinem S3_32 mit Tapatalk


Beta-User

Zitat von: Frank_Huber am 04 September 2017, 11:22:53
Vom 4.9er Linux kernel abgesehen läuft das bei mir ganz stabil mit den gpio.
Es ging auch nicht darum, dass es nicht ginge oder man nicht auch eine ganze Zeit Ruhe haben kann :) . Aber updates bedeuten m.E. immer latenten Groß-Streß, zumindest wenn GPIO-Fragen betroffen sind (was in der Regel nur bei großen updates der Fall sein dürfte; diese stehen erfahrungsgemäß aber alle 2-3 Jahre an!).
Zitat von: Frank_Huber am 04 September 2017, 11:22:53
Die ganzen Infos und Empfehlungen habe ich in meinem Fall erst gelesen als das Haus längst geplant und verkabelt war.
Ging mir in Teilen ähnlich, zumal man ja auch eine gewisse Basis braucht, um die Infos überhaupt erst mal zu verstehen und für den eigenen Anwendungsfall nutzbar zu machen; das fällt ja leider alles nicht vom Himmel und leider (?) findet man hier oder im Wiki sehr selten Hinweise in die Richtung: Lass dies oder das und mache es besser so, jedenfalls, wenn es um Hardware geht. Ist auch verständlich, denn in der Regel kennt man ja auch nur das (gut), was man selbst einsetzt. Und es ist allzu menschlich, diese einmal getroffene Entscheidung zu verteidigen ::) .
Und Microprozessorprogrammierung war ein Thema, das ich auch lange in die Kategorie "Experts only" einsortiert hatte. Ist aber - jedenfalls was Arduinos angeht - nicht zutreffend. Und läuft der Arduino mal wie gewünscht, braucht es auch keine Sicherheitsupdates :) .
Zitat
Wenn ein pi mal stirbt wegen gpio gibt's  eben nen neuen.
Und wenn es in 10 Jahren keinen pi mehr gibt dann gibt es sicherlich Nachfolger.
Klar, man kann die Dinger ja auch auf Halde legen, das ist finanziell auch kein Drama. Man muß nur dafür sorgen, dass man ein passendes Image zur Hand hat, sonst wird aus dem simplen HW-Tausch schnell eine Konfigurationsaufgabe für viele Stunden (oder noch länger)... Das ist es, was mir persönlich dabei großes Kopfzerbrechen bereitet hat. Da bin ich jetzt lieber auf dem Tripp: Irgendeine Linux-taugliche HW wird es in 20 Jahren noch geben, dazu perl und fhem und die fhem.cfg und alles läuft wie gewohnt binnen einer Stunde wieder ;) . Und eben Backup-HW für die wichtigen Interfaces
Zitat
Ich mache mir bei der zukunftstauglichkeit keine Gedanken. Wer sagt denn auf der anderen Seite dass es in 10 Jahren noch hm, max u d b dergleichen gibt?
Solange die HW lebt, wird sich auch ein interface dazu finden (CUL&Co sei es gedankt). Dass neue HW dann ggf. andere interfaces braucht, ist klar, aber bisher hat die community hier für gute (und manchmal auch schlechte) HW auch immer einen Weg gefunden 8) . Aber ausgerechnet wegen eines sehr zentralen Bauteils ggf. auf elementare Funktionen ohne Zentrale nicht zugreifen zu können, hat m.E. nichts mit Zukunftsfähigkeit zu tun.
Zitat
Und wenn alle IOs an gleicher Stelle verbaut sind kann ich auch irgendwann auf was ganz anderes umstellen. Selbst dumme 24v eltakos wären denkbar.
Die zentrale Zusammenführung der Kabel ist sicher eine sehr gute Idee, die man nur zur Nachahmung empfehlen kann! Da war bei mir irgendwann Zeit in Verbindung mit Platz im Schaltkasten und in Wand und Decke aus :'( . Und die Abhängigkeit von einer einzelnen HW-Plattform wird so definitiv verringert.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Marlen

Wäre das der richtige Arduino?
http://www.ebay.de/itm/Nano-3-0-ATMEGA328P-FT232RL-FTDI-Micro-Controller-Module-Board-for-Arduino-TE773-/202007743078?hash=item2f08998a66:g:AScAAOSwqYdZg086

Aber wo finde ich dann die richtige Software
Zitateinmal einen Arduino flaschen (am einfachsten mit der Arduino-IDE).

In dem Fall von Beta-User, bäucht  man dann weiter garnicht's am Arduino programmieren?

andies

FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

gloob

Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

CoolTux

Zitat von: Marlen am 04 September 2017, 12:28:25
Wäre das der richtige Arduino?
http://www.ebay.de/itm/Nano-3-0-ATMEGA328P-FT232RL-FTDI-Micro-Controller-Module-Board-for-Arduino-TE773-/202007743078?hash=item2f08998a66:g:AScAAOSwqYdZg086

Aber wo finde ich dann die richtige Software
In dem Fall von Beta-User, bäucht  man dann weiter garnicht's am Arduino programmieren?

Also wenn ich das richtig gelesen habe ist das ja nicht ein Arduino sondern nur ein Controller-Module-Board für den Arduino. Oder habe ich was überlesen?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Es ist im Fall von ArduCounter - sofern sich die Frage darauf bezog - sogar noch einfacher:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/firmware/ArduCounter.hex

Also einfach dieses HEX (sollte auch auf Deiner Installation schon fertig im firmware-Verzeichnis liegen) mit avrdude vom PI aus flashen...
Laut der Commandref sollte es das schon gewesen sein, der Rest wird in FHEM konfiguriert ;) .

Der verlinkte Nano - so die Lieferung den Bildern entspricht - sollte passen, ggf. prüfen, ob PIN 23 (?) des FTDI-Chips auf Ground führt, sonst verlöten (genaueres steht auch irgendwo im FHEM-Wiki...).

Und besorg Dir lieber gleich noch einen zweiten Nano und versuche mal mit der von andies verlinkten Software (oder damit), sowas wie ein Blink auf den 2. Arduino zu bringen; ist nicht verkehrt, die mit der Arduino-IDE mitgelieferten Beispielsketche mal durchzuspielen. Ist zwar C (bzw. C++), aber man erlernt dabei die Grundprinzipien, die man auch für perl (=fhem) brauchen kann ;) .

Zitat von: gloob am 04 September 2017, 12:55:14
Nimm doch gleichen einen mit WLAN dann bist du freier in der Anbindung an FHEM. Stichwort: Wemos
Wenn es unbedingt sein muß... Aber: die Programmierung ist ungleich komplexer (es sei denn, man nimmt das ESP-Äquivalent zu firmata namens ESPeasy) und man wird abhängig von anderen Infrastrukturkomponenten (WLAN).
Bei mir zuhause gibt es nur einen produktiven ESP, der macht die MiLight-Bridges (15 Gruppen auf einem Gerät statt der 4x4 Grußße auf 4 Kauf-Bridges, die dazu noch schlecht programmiert waren  ;) ). Aber auch nur, weil das dusselige Modul dazu halt Netzwerk-Technik voraussetzt...

Und wo es absolut Funk sein muß, nehme ich  MySensors, wobei ich für Funk noch die nRF's im Einsatz habe; besser wäre es mittlerweile wohl, RFM69@868MHz einzusetzen.
Oder gleich auf Asksin++ zu setzten (Selbstbau-HM ;) ). Aber soweit muß man ja nicht gehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Marlen

Jetzt verwirrt ihr mich!

Ein Wemos ist auch ein Ardurion?
Ich hab einen Wemos (als 1.Wire-WLAN-Bridge von Hexenmeister) mit ESPeasy am laufen.

Wie flasht man denn?

Beta-User

#129
Ein Wemos ist KEIN Arduino, aber eben auch ein programmierbarer Microprozessor, der sich (u.A. und nach einer gewissen Vorarbeit) mit der Arduino-IDE (wie von andies verlinkt) programmieren läßt.

Wenn Du mehr Rechenleistung brauchst, gibt es noch weitere MC-Typen, die man mit der IDE ebenfalls programmieren könnte (z.B. den "Maple" oder andere STM32-Typen).

Aber: Nimm erst mal das von Dir verlinkte Arduino Nano Board und flashe das mit der hex. Dann kannst Du die Kabel, die heute am PI hängen darauf umklemmen, Impulse zählen lassen und die Wartezeit dazu nutzen, die IDE (Software) mal in Ruhe anzusehen...

Und nochmal: Wirkliches Programmieren ist auf den ESP8266-Derivaten (wozu auch der besagte Wemos gehört) etwas komplizierter als der betagte "VW Käfer" Arduino Nano (oder Uno), der halt läuft und läuft...

Und wenn auf dem Wemos bereits ESPeasy drauf ist, sollte sich der eine oder andere PIN schlicht als Zählereingang nutzen lassen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Marlen

Ach.... man kann dann also nur zählen?

Das hilft mir wahrscheinlich in dem Fall "Stromzähler" nicht weiter.

Ich habe auf meinen Stromzähler 3x TCRT5000 hintereinander auf der Drehscheibe montiert, da diese sich auch mal zurück drehen kann.  :-X

Beta-User

...klingt nicht nach einer vorschriftsgemäßen Installation...

Arducounter kann nur zählen, alles andere müßte man programmieren. Ist aber - wie bereits gesagt - auch kein Hexenwerk, zumal ja eine Logik bestehen dürfte, nach der vor- und rückwärts gezählt wird. (Lass raten: 2 ist an, 1 geht aus = +1, 2 ist an, 3 geht aus ist -1...).
Dann ist es wahrscheinlich das einfachste, die Logik auf den Arduino zu legen und das Ergebnis alle x Minuten an FHEM zu übergeben (KeyValueProtokoll wäre via USB vermutlich die einfachste Variante, aber wie gesagt, das habe ich selbst nicht im Einsatz; im Kern wird wohl schlicht was in die serielle Konsole geschrieben, das dann von FHEM übernommen wird. Das ist aber auch programmiertechnisch einfach umzusetzten).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Marlen

Ja, die Logik funktioniert so!
Wenn ich dass dann richtig verstanden hab programmiert man den Arduino dann mit der Software die Andi verlinkt hat!?
Nur für den Arducounter würde das flashen mit FHEM reichen?

Aber warum belastet das den Raspberry wenn man direkt an den Raspberry anschließt?

andies

Wie dreht sich denn Dein Stromzähler zurück?

Netzeinspeisung ist ja ok, aber zurückdrehen kenne ich nur aus dem Osten und das war nach Aussage von demjenigen, der das hatte, eine lebensgefährliche Aktion gewesen (dafür Geldsparend, Ostgeld).
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Wernieman

Naja .. hatte mein Schwiegervater auch, als die Fotovoltaikanlage neu war und der Elektriker "Mist" gebaut hatte. Denn eigentlich DARF sich ein Stromzähler nicht rückwärtsdrehen ... wenn der Energieversorger das rauskriegt ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html