FHEM Forum

FHEM => Anfängerfragen => Thema gestartet von: Marlen am 06 September 2017, 07:50:07

Titel: [GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 06 September 2017, 07:50:07
Hallo,

mir wurde geraden, meine GPIO Eingänge (TCRT5000) weg vom Raspi und über einen Arduino laufen zu lassen!
Das ist natürlich absulutes Neuladn für mich und ich weiß garnicht so recht wo und wie ich anfangen soll!

Hab jetzt erst mal die Hardware bestellt : http://www.ebay.de/itm/SIM800C-Quad-band-Kabellos-GPRS-GSM-Modul-FUR-Raspberry-Pi-/172380695973?hash=item2822b0ada5:g:EYMAAOSwLF1YBHzo (http://www.ebay.de/itm/SIM800C-Quad-band-Kabellos-GPRS-GSM-Modul-FUR-Raspberry-Pi-/172380695973?hash=item2822b0ada5:g:EYMAAOSwLF1YBHzo) 

Ich hab aber noch einen von meinen Versuchen einen Cul zu bauen da liegen, allerdings einen billigen mit dem falschen Chip....kann ich damit noch was machen?

MEIN FRAGE(N):
-Wie fang ich an?
-Wie schreibe ich ein Programm? Arducounter reicht nicht, ich habe z.B. 3 TCRT5000 am Stromzähler welche die Scheibe abfragen 1. Drehrichtung ermitteln, 2. Umdr. zählen 3. Zeit/pro Umdr. um die Watt zu ermitteln. Ich hab keinen Schimmer wie ich das angehen soll!
-Wie bekomm ich dass dann mit FHEM zusammen?

Ich hoffe ihr könnt mir ein paar Tipps oder links geben und steinigt mich nicht gleich!  :'(

LG
  Marlen

Edit Amenophis86:
Habe mal aus ****GELÖST*** => [GELÖST] gemacht.


Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 06 September 2017, 09:09:56
Also der Reihe nach:

1. Hardware:
Du kannst beide Nanos verwenden, der CH340G-basierte hat "nur" den Nachteil, dass alle diese Nanos sich bei der Einbindung in das Linux-Dateisystem mit der genau identischen Kennung anmelden. Deswegen kann man mehrere, die z.B. an einem Pi angeschlossen sind, nicht mit der "by-id"-Methode auseinanderhalten. Das kann zu Problemem führen. Verwendet man nur einen davon bzw. macht an einem anderen Rechner Tests, ist es egal...
Auf einem Nano sind (min.) 2 Prozessoren verbaut, nämlich der USB-seriell Wandler (der ist bei den beiden Boards unterschiedlich) und der eigentliche Hauptprozessor (der ist gleich).

2. Vorbereitendes, Programme erstellen:
a) Dazu braucht es mehrere Dinge, wobei der einfachste Weg der ist, die Arduino-IDE zu installieren. Unter Linux empfielt es sich, dies zuerst über die Repo-Verwaltung zu machen, damit die ganzen weiteren Tools, die notwendig sind (avrdude, gcc usw.) mit installiert werden. Da ist aber in der Regel eine Uralt-Version drin, die man gleich wieder deinstallieren sollte (nicht aber die abhängigen Pakete) und dann eine aktuelle Version von arduino.cc runterladen.
Es gibt auch alternative Tools, aber der Einfahcheit halber solltest du erst mal dabei bleiben.

b) Wie das mit den "Sketches" (=Programmen für arduino) geht, muß man sich erarbeiten. Mit der IDE werden einige Beispiele ausgeliefert, die man durcharbeiten kann, es gibt Bücher dazu, bei arduino.cc gibt es zu diversen libs auch gute Einführungen in deren Wirkweise und Abhängigkeiten sowie einfache Beispielsketches. Auf Deutsch habe ich gefunden: http://www.arduino-tutorial.de/einfuhrung/ und http://www.arduino-tutorial.de/programmieren/. Sah ok aus, habe das aber nicht getestet.

c) Die Kommunikation mit FHEM soll via USB erfolgen, wenn ich das richtig verstanden habe.
Dazu solltest du erst mal verstehen, wann ein Arduino was auf die Konsole schreibt. In der IDE gibt es dazu einen Menüpunkt "Serielle Konsole", es sollten auch Beispiele mit der IDE geliefert worden sein. Dabei auf die Baudrate achten.

3. Konkrete Problemlösung
a) Einbindung in FHEM
Mein Verdacht ist, dass das KeyValueProtokoll hier die richtige Variante wäre. Da habe ich aber keine Erfahrung und bisher auch keine einfache Anleitung gesehen, scheint aber "selbsterklärend" zu sein. Im Kern wird einfach immer mal wieder ein Wert (mit Kennung?) über die USB-Schnittstelle weitergegeben, das FHEM-Modul macht den Rest. Solltest du einfach mal testen, z.B. indem du einfach einen Zählerwert alle 10 sec. an FHEM schickst und beobachtest, ob und was das Modul damit macht...
b) Haben wir uns darauf festgelegt, würde ich mit einem einfachen Counter für einen der TCRT5000 anfangen, um folgendes zu machen:
- Abfragen des mit bounce2() eingebundenen INPUT_PULLUP-PINs
- Zählen, wenn "gefallen"
- Alle x Sekunden Senden des Zählerwerts an FHEM (millis(), sollte unter non-blocking loop() zu finden sein; wenn du soweit bist, können wir das auch gerne zusammen machen). Dann solltest Du entscheiden, ob der Zähler dann wieder zurückgesetzt wird oder weitergezählt werden soll (ich neige zum Zurücksetzen).
Funktioniert das, kannst Du die komplexere Logik mit den 3 TCRTs angehen. Da sind dann einige Abfragen mehr in der loop() notwendig.

Gruß und viel Spaß beim Einarbeiten,

Beta-User
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 06 September 2017, 10:05:23
Danke, schon mal!

Dann werde ich heute Abend Arduino-IDE installieren.....denk aber das hab ich schon drauf! ...ich nutze Windows.

Dann kann ich ja mit meinen billig Arduino schon mal herumprobieren, kann ich einfach einen Taster zwischen 3,3V und einen GPIO legen?

Sieht man dann live ob was passiert?

LG
Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 06 September 2017, 10:30:46
 ::) Solche Trockenübungsfragen bringen dich eher nicht weiter...

Für einen einfachen Button:
- https://github.com/arduino/Arduino/blob/master/build/shared/examples/01.Basics/DigitalReadSerial/DigitalReadSerial.ino
Wie es geht, steht bei den Beispielen in der Regel im Sketch, manchmal muß man einfach experimentieren. Die PINs sind aber 5V-tolerant, kann also kaum schiefgehen ;)
- Mit debounce(): https://github.com/arduino/Arduino/blob/master/build/shared/examples/01.Basics/DigitalReadSerial/DigitalReadSerial.ino (da steht auch zur Verkabelung was drin...)

- debounce2() mit INPUT_PULLUP als anzustrebender Lösung hatte ich dir ja schon empfohlen, und da du SW-Installationen unter Windo.* beherrschst, wird das Bedienen einer Suchmaschine deiner Wahl vermutlich auch in deinem aktuellen Kompetenzumfang enthalten sein 8) .

Vor Durchführung deiner ersten Tests werde ich daher erst mal nix mehr schreiben :P .
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 06 September 2017, 21:20:42
O.k. hab das jetzt so gemacht, wenn ich den Serial-Monitor anschaue, laufen 0 durch, drück ich den Taster laufen eine Zeit lang 1 durch.....bedeutet das es passt?
Mehr kann man da nicht sehen?
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 06 September 2017, 22:11:15
Je nach Sketch halt.
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 07:43:29
Hab dann gestern nochmal die andere Variante versucht, mit ArduCounter.

Einbinden in FHEM, flashen...hat geklappt, aber scheinbar hab ich Hardwareseitig was falsch gemacht.

Hatte einen Taster zwischen 5V und D5.

Meine def:
defmod AC ArduCounter /dev/ttyUSB2@38400
attr AC userattr pinD2 pinD5 pinD6
attr AC factor 1000
attr AC flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] -b 57600
attr AC interval 60 300
attr AC pinD2 falling pullup
attr AC pinD5 falling pullup 30
attr AC pinD6 rising

setstate AC opened
setstate AC 2017-09-07 07:38:49 pin5 0
setstate AC 2017-09-07 07:40:19 pin6 109
setstate AC 2017-09-07 07:38:49 power5 0.000
setstate AC 2017-09-07 07:40:19 power6 0.000
setstate AC 2017-09-06 22:53:29 state opened


Passt doch so?

LG
  Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 07 September 2017, 09:37:07
ZitatHatte einen Taster zwischen 5V und D5.
Versuch's mal mit D5->GND; könnte sein, dass das besser der Funktionalität des Logikbausteins auf dem TCRT-Modul entspricht...

Für später: warum behandelst du D6 anders? Ist doch dieselbe HW, die da dran hängt, und dieser PIN wird auch nicht direkt auf dem Arduino hardwareseitig schon entprellt (anders als D2&D3). Ich vermute mal, dass du aus diesem Grund da entgegen deiner Erwartung bereits ein Zählergebnis hast (oder wo kommen das her: "setstate AC 2017-09-07 07:40:19 pin6 109").

Ansonsten solltest du einen Browser-Refresh machen, nachdem die ersten Ergebnisse geliefert worden sind (hier: 60+Sec.). Sonst werden neue Readings erst mal nicht angezeigt ;) .

Und: Dir ist schon klar, dass mit dem ArduCounter die spezielle Zählart, die du brauchst m.E. nicht abgebildet werden kann?
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 12:25:25
ZitatVersuch's mal mit D5->GND; könnte sein, dass das besser der Funktionalität des Logikbausteins auf dem TCRT-Modul entspricht...
Werd ich heute abend mal machen....
ZitatFür später: warum behandelst du D6 anders? Ist doch dieselbe HW, die da dran hängt, und dieser PIN wird auch nicht direkt auf dem Arduino hardwareseitig schon entprellt (anders als D2&D3). Ich vermute mal, dass du aus diesem Grund da entgegen deiner Erwartung bereits ein Zählergebnis hast (oder wo kommen das her: "setstate AC 2017-09-07 07:40:19 pin6 109").
Ich hab die Definition aus einen Beispiel einfach reingeladen! Was meinst du mit entprellt?
ZitatAnsonsten solltest du einen Browser-Refresh machen, nachdem die ersten Ergebnisse geliefert worden sind (hier: 60+Sec.). Sonst werden neue Readings erst mal nicht angezeigt ;) .
Is mir schon klar!  ;D
ZitatUnd: Dir ist schon klar, dass mit dem ArduCounter die spezielle Zählart, die du brauchst m.E. nicht abgebildet werden kann?
Ja, ist mir schon klar! Ich wollte halt mal den ArdCounter ausprobieren, weil ich mit dem Sketch schreibe nicht weiter gekommen bin.
Für Wasseruhr und Gaszähler würde er ja gehen, aber warum 2 Device wenn man es auch mit einen machen kann.

Wie erstelle ich einen Counter im Sketch und wie komm ich an die Daten von FHEM aus?

LG
Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 07 September 2017, 13:31:12
Zitat von: Marlen am 07 September 2017, 12:25:25
Ich hab die Definition aus einen Beispiel einfach reingeladen! Was meinst du mit entprellt?
Zitat
Is mir schon klar!
Leider ist es nicht so einfach zu erkennen, was dir klar ist und was nicht. Und eigentlich widerstrebt es mir auch, alles ins Detail vorzukauen, ohne dass der Geholfene sich die Mühe macht, wenigstens ein klein wenig über den Beispielcode nachzudenken. Den Eindruck habe ich leider nicht :( >:( :( . Da ich andererseits davon ausgehe, dass es ein paar "Anfänger" gibt, die sich vielleicht trauen würden, es auch mal zu versuchen, wenn du das hinbekommst, nochmal die nachdrückliche Bitte: nimm ggf. die Stichworte und bemühe mal selbst eine Suchmaschine deiner Wahl :-* . So bin ich nichtmal sicher, ob du den richtigen USB-Anschluß ausgewählt hast, da auch diese Angabe mit der commandref zu arducounter übereinstimmt...

Für die Ungeduldigen zum Thema Entprellen: Wikipedia (https://de.wikipedia.org/wiki/Prellen) und Umsetzung für Arduino mit bounce2 (https://github.com/thomasfredericks/Bounce2). In der commandref zu arducounter nennt sich das dann so:
ZitatThe last argument is also optional and specifies a minimal pulse length in milliseconds
...wie oft hatte ich das Stichwort Entprellen bzw. bounce()/bounce2 in diesem Thread erwähnt?!?
Zitat
Wie erstelle ich einen Counter im Sketch und wie komm ich an die Daten von FHEM aus?
ixquick kommt mit den Suchbegriffen "arduino" und "counter" recht schnell zu diesem hier: https://www.arduino.cc/en/Tutorial/StateChangeDetection. Den kannst du als Basis nehmen, solltest dazu aber noch bounce2 zum Entprellen einbauen (da helfe ich gerne, das ist nicht ganz selbsterklärend).

Die Daten soll dann der Sketch über die serielle Konsole an FHEM übergeben mittels kvp, (3. Mal erwähnt, wenn ich richtig gezählt habe). Das scheint auch nicht selbsterklärend zu sein, aber da helfe ich dann auch gerne, die Doku ist wenig aufschlußreich.
Was ich dazu bisher verstanden habe: wir müssen den Arduino als Jeelink definieren, dazu ein keyValueProtocol-Device und den Sketch dazu bringen, dass er nicht nur "0" und "1" an die serielle Konsole schreibt, sondern sowas in der Art (commandref zu keyValueProtocol:
Zitat
The Sketch can then send short Keys, which will get translated to long names.
Example: attr myKVP Mapping T=Temperature,H=Humidity
If the sketch then sends: OK VALUES T=12,H=70
you will get the readings Temperature and Humidity with the Values 12 and 70

Damit sollten sich dann alle drei Zähler über einen Arduino abbilden lassen, das ist eine gute Idee :) . (Und von mir aus noch ein BME280 oder anderer komplexer Sensor, dafür sollte der Platz auch noch reichen).

Vielleicht wärst du so gütig, den Versuch zu unternehmen, heute Abend den Arduino
- auf Grundlage des og. Zählersketches
- mit Hilfe der bereits verlinkten Sketchs (und der Beispiele in der IDE zur seriellen Ausgabe)
- ohne Entprellen
dazu zu überreden, dass er über die serielle Konsole den "magischen Text" "OK VALUES Gas=<Zählerwert>" für einen PIN ausgibt und dann den Zähler z.B. nach 10 Tastendrücken wieder auf "0" setzt.

Vielelicht hast du Glück und ich bau das nach, um zu verstehen, wie das kvp tickt (wenn uns vorher niemand nettes da auf die Sprünge hilft, insbesondere was unter "<Type>" und "<ID>" zu verstehen ist).
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 14:25:50
Ich bin zwar blond, aber das man den Browser aktualisieren bzw. ein "get <device> info" ausführen muss um aktuelle Zahlen zu sehen ist mir schon klar!

Mit bounce war ich die ganze Zeit bei dem FHEM Attribut "debounce_in_ms".

Und das https://github.com/thomasfredericks/Bounce2/archive/master.zip (https://github.com/thomasfredericks/Bounce2/archive/master.zip) muss ich dann in der Arduino IDE irgendwie in die Library bringen, oder wie?

Aber dann schreibst du ja wieder ohne Entprellen
ZitatVielleicht wärst du so gütig, den Versuch zu unternehmen, heute Abend den Arduino
- auf Grundlage des og. Zählersketches
- mit Hilfe der bereits verlinkten Sketchs (und der Beispiele in der IDE zur seriellen Ausgabe)
- ohne Entprellen

Ich schau mal was ich heute Abend machen kann!

LG
  Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 07 September 2017, 14:58:14
Zitat von: Marlen am 07 September 2017, 14:25:50
Und das https://github.com/thomasfredericks/Bounce2/archive/master.zip (https://github.com/thomasfredericks/Bounce2/archive/master.zip) muss ich dann in der Arduino IDE irgendwie in die Library bringen, oder wie?

Aber dann schreibst du ja wieder ohne Entprellen
(Kommentare zu "war ich die ganze Zeit ..." erspare ich uns angesichts der konkret verlinkten bounce()-Ansätze für Arduino. Immerhin scheinst Du aber das Problem und den Lösungsansatz zu kennen, allerdings eben auf anderer HW).

Die lib kannst du (nach meiner Erinnerung) einfach über den library-Manager direkt in der IDE (https://www.arduino.cc/en/Guide/Libraries (https://www.arduino.cc/en/Guide/Libraries)) installieren.

Das mit dem Entprellen führt ja "nur" zu verlässlicheren Ergebnissen. Deshalb war die Idee, erst mal das Grundgerüst zu erstellen und erst später nachzurüsten. Du darfst das mit dem debounce() aber natürlich auch gleich mit erledigen.
Wenn Dir das gelingt und dann wieder langweilig ist:
- Wasser und Gas könnten auch mit interrupt-basierter Zählweise erfaßt werden. Basis wäre z.B. der Sketch für den Impulszähler von MySensors (https://www.mysensors.org/build/pulse_power) (PINs 2 und 3, ohne das Drumrum von MySensors). Wenn: Fange aber erst mal mit PIN 3 an (wie in dem Beispiel)! (Du kannst dir aber gleich ansehen, wie man es löst, nur alle 20 Sekunden einen Wert zu senden (würde das aber tendenziell eher verlängern...) Die Variablen dazu sind diese, da kannst du nachsehen, wo die im Sketch wie definiert bzw. verändert werden:
ZitatsendTime = now - lastSend > SEND_FREQUENCY;
)
- Die 3 PINs für den "speziellen" Zähler könntest du am einfachsten mit einer for-loop debouncen und Abfragen. Zum Ausschlachten: https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33# (https://forum.mysensors.org/topic/4847/multi-button-relay-sketch/33#). Die etwas einfachere Variante (ohne array und for-loop) mit 2 buttons ist als Beispiel in der lib bounce2 enthalten (wird mitinstalliert, wenn das über den lib-Manager gemacht wird).

Aber wie gesagt: ab einschließlich debounce() ist das für fortgeschrittene Einsteiger, da bin ich gerne behilflich ;) .
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 22:03:36
So, jetzt bin ich schon mal ein bisschen glücklicher....denn es funktioniert schon mal was!
Hier mein Sketch für meine "speziellen" Stromzähler:

// Stromzähler PIN's
const int  buttonPin1 = 2;
const int  buttonPin2 = 3;
const int  buttonPin3 = 4;

// Variablen
int buttonPushCounter1 = 0;
int buttonPushCounter2 = 0;
int buttonPushCounter3 = 0;
int buttonState1 = 0;
int buttonState2 = 0;
int buttonState3 = 0;
int lastButtonState1 = 0;
int lastButtonState2 = 0;
int lastButtonState3 = 0;
int Strom_Counter = 0;
int merker = 0; // 1=vor 2=gez 3=rueck 4=erl

void setup() {
  // Eingangs PIN's defineiren
  pinMode(buttonPin1, INPUT);
  pinMode(buttonPin2, INPUT);
  pinMode(buttonPin3, INPUT);
  // Ausgangs PIN's defineiren
  //pinMode(ledPin, OUTPUT);
  // initialize serial communication:
  Serial.begin(9600);
}


void loop() {
  // read the pushbutton input pin:
  buttonState1 = digitalRead(buttonPin1);
  buttonState2 = digitalRead(buttonPin2);
  buttonState3 = digitalRead(buttonPin3);
  // ################# 1. Eingang ##################### START ######################
  if (buttonState1 != lastButtonState1) {
    if (merker != 2) { // 1=vor 2=gez 3=rueck 4=erl
    if (buttonState1 == HIGH) {
      // if the current state is HIGH then the button went from off to on:
      merker = 1; // 1=vor 2=gez 3=rueck 4=erl
      Serial.println("PIN1 on");
      Serial.println(merker);
    } else {
      //Serial.println("PIN1 off");
    }
  } else {
    merker = 4; // 1=vor 2=gez 3=rueck 4=erl
  }}
    delay(50);
  lastButtonState1 = buttonState1;
  // ################# 2. Eingang ##################### START ######################
if (buttonState2 != lastButtonState2) {
    // if the state has changed, increment the counter
    if (buttonState2 == HIGH) {
// ###################### dreht VOR ###########################
      if (merker == 1) { // 1=vor 2=gez 3=rueck 4=erl
        merker = 2; // 1=vor 2=gez 3=rueck 4=erl
        Strom_Counter++;
        Serial.println("-->");
      }
// ###################### dreht ZURUECK ###########################
      if (merker == 3) { // 1=vor 2=gez 3=rueck 4=erl
        merker = 2; // 1=vor 2=gez 3=rueck 4=erl
        Strom_Counter--;
        Serial.println("<--");
      }
      Serial.println("PIN2 on");
      Serial.println(merker);
       Serial.println("Strom_Counter: ");
      Serial.println(Strom_Counter);
    } else {
      //Serial.println("PIN2 off");
    }
    // Delay a little bit to avoid bouncing
    delay(50);
  }
  lastButtonState2 = buttonState2;
  // ################# 3. Eingang ##################### START ######################
  if (buttonState3 != lastButtonState3) {
    if (merker != 2) { // 1=vor 2=gez 3=rueck 4=erl
    if (buttonState3 == HIGH) {
      // if the current state is HIGH then the button went from off to on:
      merker = 3; // 1=vor 2=gez 3=rueck 4=erl
      Serial.println("PIN3 on");
      Serial.println(merker);
    } else {
      // if the current state is LOW then the button went from on to off:
      //Serial.println("PIN3 off");
    }
  } else {
    merker = 4; // 1=vor 2=gez 3=rueck 4=erl
  }}
    delay(50);
  // save the current state as the last state, for next time through the loop
  lastButtonState3 = buttonState3;
}


Aber wie komm ich jetzt an die Variable "Strom_Counter" in FHEM?

LG
  Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 23:16:22
So, hab jetzt noch für die Übergabe folgendes eingefügt:

Serial.print("OK VALUES ARDU 1 ST=");
       Serial.print(Strom_Counter);


Und in FHEM folgende Device angelegt:

defmod Arduino JeeLink /dev/ttyUSB2@38400
attr Arduino event-on-change-reading .*
attr Arduino flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] modprobe usbserial vendor=0x0403 product=0x6001
attr Arduino verbose 4

setstate Arduino opened
setstate Arduino 2017-09-07 23:05:08 state opened


und

defmod KeyValueProtocol_Strom KeyValueProtocol ARDU 1
attr KeyValueProtocol_Strom IODev Arduino
attr KeyValueProtocol_Strom verbose 4


Aber leider kommt nicht's an  :'(

Guten Nacht!  :-*
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 07 September 2017, 23:34:07
Ohh man.....

defmod Arduino JeeLink /dev/ttyUSB2@38400
das muss natürlich
defmod Arduino JeeLink /dev/ttyUSB2@9600
Kaum macht man es richtig, geht es schon!  ;)

Aber jetzt GUTE NACHT!
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 07:34:13
Guten Morgen,

mir ist aufgefallen, dass dass KeyValueProtocol auch die nächsten Serial.printIn mit liest!
KeyValueProtocol_Strom 2017-09-07 23:31:22 ST 2PIN3 on

Da sollte doch nur:
Serial.print("OK VALUES ARDU 1 ST=");
       Serial.print(Strom_Counter);

ankommen!

Und noch eine Frage:
Kann man mit "set Arduino Flash ......." einen Sketch von FHEM aus flashen? Oder muss man das Teil immer abstöpseln und mit dem PC hin?

LG
  Malren
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 09:07:35
Moin,

schön, dass du vorankommst.

1. Du mußt die Zeile schon umbrechen, sonst wird der Rest einfach weiter in dieselbe Zeile geschreiben (und daher von den "Magic Words" erfasst). Also so:
Serial.print("OK VALUES ARDU 1 ST=");
       Serial.println(Strom_Counter);

Generell empfiehlt es sich aber, mit Ausgaben an der seriellen Konsole sparsam umzugehen, das braucht einiges an Speicher, und der ist auf einem Arduino nano eben begrenzt...
Unnötige serielle Ausgaben daher löschen oder deaktivieren (siehe z.b. #MY_DEBUG mit #ifdef/#endif in den MySensors-Sketchen)).

2. Flashen
Da der Arduino als Jeelink definiert ist, kann man den zugehörigen flash-Aufruf nutzen ;) . Du mußt halt dann erst das hex erzeugen, auf den Pi übertragen, die richtigen Rechte haben, dann kann es losgehen...

3. Baudrate:
Kannst du im Sketch (konkret: setup()-Bereich) einstellen, damit es den Jeelink-Standards entspricht:
Serial.begin(38400);
4. Sketch und allgemeines:
- Sei doch so freundlich, die PINs 2 und 3 erst mal außen vor zu lassen. Die sind "speziell" (interrupt-fähig), der Stromzähler sollte also z.B. 4-6 nutzen ::)
- Über welchen Sketch reden wir derzeit? Den aus Post #13?
Der überträgt ja einzelne Puls-Infos. Das ist m.E. nicht so das "Gelbe vom Ei". Denn dann muß sich der Pi bzw. FHEM darüm kümmern, den ganzen Kleckerkram zu überwachen.
Vorschlag daher nochmal: Wir lassen den Arduino eine Zeit lang zählen, und am Ende dieser Zeit teilen wir FHEM mit, dass der Stromzähler sich um x Zähler insgesamt bewegt hat, der Wasserzähler um y und Gas um z. Dann setzen wir diese Zähler auf dem Arduino zurück und das Spiel beginnt für den Arduino von vorne. Dann hat der Arduino wenigstens ein wenig zu tun und der Pi kann in der Zeit wichtigeres erledigen und wird nicht unnötig blockiert ;) .
Bau doch bitte den Sketch in Schritt eins nach dem Muster von StateChangeDetection (https://www.arduino.cc/en/Tutorial/StateChangeDetection) (Post #10) um, so dass er nur sendet, wenn 10 positive Pulse erreicht sind und dann den Zähler wieder zurücksetzt. Wenn du die bisherigen posts nochmal durchgehst, findest du auch das Material, um das dann so umzubauen, dass z.B. alle Minute der Zählerstand übermittelt wird (Schritt 2).
- Das mit delay() to avoid bouncing ist m.E. nicht zielführend. Um das Rad nicht neu zu erfinden, sollte die lib bounce2 für das Entprellen genutzt werden. Das kannst du also wieder rausnehmen und in Schritt 3 dann nach bounce2 umbauen, den Beispielsketch für mehrere Buttons aus der lib dafür als Referenz nehmen...
- Schritt 4 wäre dann, einen weiteren Zähler dazu zu nehmen (PIN 3), interrupt-basiert
- Schritt 5: Zähler 3 an PIN 2...
Fertig; weiteres Flashen für die Lebenszeit des Arduino: überflüssig ;D (Es sei denn, du willst dann noch eine 1wire-Strecke dran machen, einen i2c-Sensor anschließen oder doch noch zum Mond fliegen ;D ;D ;D ).
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 10:21:52
Moin,

was heißt umbrechen, wie definierst du das das die ";" untereinander stehen?

Die Baudrate also auf 38400 einstellen?

Ich war eigentlich froh darum, dass es geht das ich jede Zähleränderung live mitbekomme in FHEM, da ich dort dann die Zeit Messe pro Umdrehung und so die Watt berechne die in dieser Zeit gelaufen sind und dieses von einen Plot schrieben lasse.
Man könnte höchstens vielleicht die Watt Berechnung noch auf den Arduino verlagern, aber dann je Umdrehung an FHEM senden!
Dazu müsste man aber die Zeit messen.

Is das so schlimm? Wenn der Arduino alle 10 Min. (wenn ich nicht gerade am kochen bin oder der Trockner läuft) einen Zählerstand schickt? Schneller dreht sich die Scheibe nicht!

Das mit bounce2 muss ich mir nochmal anschauen....hat auf den ersten blick kompliziert ausgeschaut!

Was bedeutet das
ZitatPINs 2 und 3 sind "speziell" (interrupt-fähig)
?

LG und vielen dank für deine Unterstützung
Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 10:42:22
Zitat von: Marlen am 08 September 2017, 10:21:52
was heißt umbrechen, wie definierst du das das die ";" untereinander stehen?
Umbrechen:
Serial.println(Strom_Counter); statt  Serial.print(Strom_Counter);
Die konkrete Lage der ";" sind nur ein optisches Thema (sie müssen dastehen, da dadurch jeweils eine Anweisungabgeschlossen wird), wieviele Leerzeichen, Zeilenumbrüche des Texts usw. da stehen, ist in dem Zusammenhang irrelevant.
Zitat
Die Baudrate also auf 38400 einstellen?
Ja, eben im Sketch und der FHEM-DEF
Zitat
Is das so schlimm? Wenn der Arduino alle 10 Min. (wenn ich nicht gerade am kochen bin oder der Trockner läuft) einen Zählerstand schickt?
Schneller dreht sich die Scheibe nicht!
OK, dann kann man das natürlich so lassen.

Bei den anderen beiden Zählern würde ich das aber anders lösen...

Zitat
Das mit bounce2 muss ich mir nochmal anschauen....hat auf den ersten blick kompliziert ausgeschaut!
Das ist eben ein Schritt mehr, das macht es auf den ersten Blick etwas unübersichtlich: Es wird statt direkt den gerade aktuellen Wert des GPIO auf Anfrage erst über eine gewisse Zeit (die Zeit x in debounce(x)) entprellt (also in der Zeit mehrfach ausgewertet und daraus dann erst schlußgefolgert, ob jetzt wirklich ein HIGH oder LOW vorliegt), und dann der entprellte Wert zurückgegeben und in eine eigene Variable geschrieben. Dann greifen wir statt auf den GPIO auf diese entprellte Variable zu und werten die aus; ist ein kleiner Umweg, aber sooo kompliziert ist es m.E. auch nicht, die beiden Grundbeispiele in der lib nachzuvollziehen.

PIN 2 und 3 werden vom Prozessor anders verwaltet: der entprellt nach meiner Kenntnis bereits (?) und kann auch RISING und FALLING unterscheiden (oder auf beides reagieren). Damit wird die Vorarbeit über debounce und die Frage, ob jetzt der Status von HIGH auf LOW gewechselt hat überflüssig. Daneben (hier nicht relevant) kann ein Arduino das "im Schlaf", er wird also ggf. aufgeweckt, um die sog. interruptroutine abzuarbeiten und schläft dann weiter ;) .
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 11:00:41
O.k. wenn ich debounce einbaue, brauch ich das
if (buttonState1 != lastButtonState1) {
nicht mehr!

ZitatSerial.println(Strom_Counter);
statt 
Serial.print(Strom_Counter);

Ich dachte .println steht für "intern" ???
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 11:09:46
Zitat von: Marlen am 08 September 2017, 11:00:41
O.k. wenn ich debounce einbaue, brauch ich das
if (buttonState1 != lastButtonState1) {
nicht mehr!
Doch! Aber:
aus
buttonState1 = digitalRead(buttonPin1);wird dann eben (sowas in der Art wie)

debouncer1.update();
buttonState1 = debouncer1.read();
Bitte für das korrekte coding in den Beispielcode bei debounce2 sehen! Die Voraussetzungen, dass diese beiden Zeilen sinngemäß funktionieren, müssen auch erst definiert werden ;) .
Zitat
Ich dachte .println steht für "intern" ???
Manchmal hilft Ausprobieren gegen solche Irrtümer ;) ... Oder eben das Nachschlagen bei Arduino.cc :-*  (https://www.arduino.cc/en/Serial/Print)
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 11:13:48
ZitatDoch! Aber:
aus

Code: [Auswählen]

buttonState1 = digitalRead(buttonPin1);

wird dann eben (sowas in der Art wie)

Code: [Auswählen]

debouncer1.update();
buttonState1 = debouncer1.read();

Bitte für das korrekte coding in den Beispielcode bei debounce2 sehen! Die Voraussetzungen, dass diese beiden Zeilen sinngemäß funktionieren, müssen auch erst definiert werden ;) .

Ja, so hab ich das ja gemeint!  :D
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 11:29:18
Zitat von: Marlen am 08 September 2017, 11:13:48
Ja, so hab ich das ja gemeint!  :D
Dann schreib das doch auch so...
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 12:37:10
Naja, so halt
https://github.com/thomasfredericks/Bounce2 (https://github.com/thomasfredericks/Bounce2)

Aber dazu find ich kein Beispiel:
Zitatsiehe z.b. #MY_DEBUG mit #ifdef/#endif in den MySensors-Sketchen)).

Kann man nicht irgendwie

Serial.println(Merker) if .......;
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 12:54:20
Zitat von: Marlen am 08 September 2017, 12:37:10
Naja, so halt
https://github.com/thomasfredericks/Bounce2 (https://github.com/thomasfredericks/Bounce2)
Genauer wäre folgendes "so halt" gewesen: https://github.com/thomasfredericks/Bounce2/blob/master/examples/bounce2buttons/bounce2buttons.ino
Zitat

Aber dazu find ich kein Beispiel:
Kann man nicht irgendwie

Serial.println(Merker) if .......;

Argh, das mit dem #ifdef ist in vielen MySensors-Beispielen ziemlich rausgenommen worden, ist mir bislang nicht aufgefallen. Aber hier ist noch ein Beispiel übriggeblieben: https://github.com/mysensors/MySensors/blob/development/examples/BatteryPoweredSensor/BatteryPoweredSensor.ino. Man kann das auch ausbauen (https://github.com/rejoe2/blind-control/blob/master/arduino/WintergartensteuerungV4/WintergartensteuerungV4.ino)...
Deine Idee mit dem if is
a) perl-Schreibweise (nachstehendes if kennt C/C++ nicht) und
b) leider nicht zielführend, da trotzdem der im wenn-Fall auszugebende Text mit eincompiled werden würde. Das ist mit der #define MY_DEBUG-Vorgehensweise nicht so: Da wird der Compiler angewiesen, das zwischen #ifdef und #endif stehende zu ignorieren, also nicht mit zu übersetzen, wenn das flag im Header nicht gesetzt (bzw. auskommentiert) ist...

Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 13:02:42
Ach so.....
dann einfach zum testen am PC
so define MY_DEBUG
und
vor dem Hochladen so:
//define MY_DEBUG
???
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 13:24:11
Jein:
das "#" muß zwingend vor das "define"; es handelt sich um Compiler-Anweisungen.

Zum Testen mit erweiterter Ausgabe: nicht auskommentieren und hochladen.
Wenn alles paßt und keine Ausgaben (mehr) erforderlich sind: auskommentieren und hochladen...

Also erst so:
#define MY_DEBUG
und dann so:
//#define MY_DEBUG
Die #ifdef MY_DEBUG bzw. #endif -Zeilen bleiben einfach so stehen.
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 13:37:29
O.k. dann kann ich heute Nacht wieder was machen!  ;)

Danke!  :-*
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 15:02:07
Ich bin gerade auf das FHEM Modul "ElectricityCalculator" gestossen!

Das ist ja echt gut! Das berechnet auch gleich die Watt und hält den Zählerstand zum 1. des Monats fest und noch viele andere Werte!!!

Aber wie macht man das, dann...... ich möchte den gesamtzähler in FHEM belassen und nicht auf den Ardurion.....was wäre wenn man vom Ardurion nur eine "+1" oder "-1" liefern lässt! Und das dann mit einen Notify verarbeitet!
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 08 September 2017, 15:27:58
Das Modul kenne ich nicht näher und kann daher nichts dazu sagen, wie es im Detail funktioniert und welche Voraussetzungen benötigt werden.

Das mit einem Notify auf einen neuen Wert vom Arduino sollte kein Problem sein, du hast ja so langsam aber sicher in der Hand, was der Arduino (wann) an FHEM schickt, oder etwa nicht?!? ;) Das war doch der große Vorteil der Lösung, statt der PI-GPIO's eine weitere Ebene namens Arduino einzuziehen und dort eine Vorverarbeitung zu machen ;D ;) ;D 8) ...

Wenn der Electricity-Calculator irgend einen Zählerwert braucht, mußt du das beim kvp innerhalb FHEM lösen (da kann man nach meiner Kenntnis keinen aktuellen Zählerwert an den Arduino senden und den dann wieder ein weitergezähltes Ergebnis rückmelden lassen, wie das z.B. der Zählersketch von MySensors macht). Das könntest du also in der Tat wie von dir beschrieben mit einem notify und
- "setreading" lösen (oder einem userreading)
- oder einen Dummy füllen
- ...
ganz nach Belieben, wir sind ja bei FHEM und programmieren unsere Sensoren und deren Auswertung selbst... 8)

Und da macht nach deiner Darstellung für den Stromzähler ein 1 bzw. -1 für jede Umdrehung Sinn.
Für Gas und Wasser kannst du das anders lösen (z. B. alle 5 Minuten), ggf. zusätzlich einen Alarm, wenn in den 5 Min. mehr als y Pulse durchlaufen (Wasserrohrburch nach dem Zähler oder es duschen alle auf einmal) und solche Sachen halt... Es gibt übrigens Schwestermodule zu dem von dir genannten ;) . Und für einen "Alarm: Wasserrohrbruch" müßtest du eben ein eigenes notify erfinden ::) 8)
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 22:18:53
Soo .... jetzt schaut es so aus, was sagst du dazu?


#include <Bounce2.h>

// Stromzähler PIN's
#define BUTTON_PIN_1 4
#define BUTTON_PIN_2 5
#define BUTTON_PIN_3 6
Bounce debouncer1 = Bounce();
Bounce debouncer2 = Bounce();
Bounce debouncer3 = Bounce();
// Wasser PIN
#define BUTTON_PIN_w 7
Bounce debouncerw = Bounce();
// Gas PIN
#define BUTTON_PIN_g 8
Bounce debouncerg = Bounce();
// Variablen
int Wasser_Counter = 0;
int merkerw = 0;
int Gas_Counter = 0;
int merkerg = 0;
int merker = 0; // 1=vor 2=gez 3=rueck 4=erl
// fuer Timer
const unsigned long INTERVAL = 1000L*60* 1; // ############## 1 Minuten
unsigned long lastRun = 0 ;

// #########################             Enable debug prints to serial monitor
//#define MY_DEBUG
//##########################

void setup() {

  pinMode(BUTTON_PIN_1,INPUT_PULLUP);
  debouncer1.attach(BUTTON_PIN_1);
  debouncer1.interval(100); // interval in ms

  pinMode(BUTTON_PIN_2,INPUT_PULLUP);
  debouncer2.attach(BUTTON_PIN_2);
  debouncer2.interval(100); // interval in ms
 
    pinMode(BUTTON_PIN_3,INPUT_PULLUP);
  debouncer3.attach(BUTTON_PIN_3);
  debouncer3.interval(100); // interval in ms

    pinMode(BUTTON_PIN_w,INPUT_PULLUP);
  debouncerw.attach(BUTTON_PIN_w);
  debouncerw.interval(100); // interval in ms

     pinMode(BUTTON_PIN_g,INPUT_PULLUP);
  debouncerg.attach(BUTTON_PIN_g);
  debouncerg.interval(100); // interval in ms

  Serial.begin(38400);
}

void loop() {
Strom();
Wasser();
Gas();
if ( millis() - lastRun >= INTERVAL ) {
   senden();
   lastRun += INTERVAL;
}}
void senden(){
  if (Wasser_Counter != 0) {
    Serial.print("OK VALUES ARDU 1 Wasser1Min=");
        Serial.println(Wasser_Counter);
        Wasser_Counter = 0;
  }
   if (Gas_Counter != 0) {
    Serial.print("OK VALUES ARDU 1 Gas1Min=");
        Serial.println(Gas_Counter);
        Gas_Counter = 0;
  }}

void Wasser(){
  debouncerw.update();
  int valuew = debouncerw.read();
  if ( valuew == LOW) {
    if (merkerw == 0) {
    Wasser_Counter++;
    merkerw = 1;
    #ifdef MY_DEBUG
    Serial.print("Wasser =");
    Serial.println(Wasser_Counter);
    #endif
    }
  }else{
    merkerw = 0;
  }}

void Gas(){
  debouncerg.update();
  int valueg = debouncerg.read();
  if ( valueg == LOW) {
    if (merkerg == 0) {
    Gas_Counter++;
    merkerg = 1;
    #ifdef MY_DEBUG
    Serial.print("Gas =");
    Serial.println(Gas_Counter);
    #endif
    }
  }else{
    merkerg = 0;
  }}

void Strom() {
  // Update the Bounce instances :
  debouncer1.update();
  debouncer2.update();
  debouncer3.update();
// Get the updated value :
  int value1 = debouncer1.read();
  int value2 = debouncer2.read();
  int value3 = debouncer3.read();

  // ################# 1. Eingang ##################### START ######################
   if ( value1 == HIGH) {
    if (merker != 2 && merker != 1) { // 1=vor 2=gez 3=rueck 4=erl
      merker = 1; // 1=vor 2=gez 3=rueck 4=erl
      #ifdef MY_DEBUG
      Serial.println("PIN1 on");
      Serial.println(merker);
      #endif
  }
    if (merker == 2 ) {
    merker = 4; // 1=vor 2=gez 3=rueck 4=erl
    }}
 
  // ################# 2. Eingang ##################### START ######################
if ( value2 == HIGH && value1 == LOW && value3 == LOW && merker != 2) {
// ###################### dreht VOR ###########################
      if (merker == 1) { // 1=vor 2=gez 3=rueck 4=erl
        merker = 2; // 1=vor 2=gez 3=rueck 4=erl
        Serial.print("OK VALUES ARDU 1 StromUm=");
        Serial.println("+1");
        #ifdef MY_DEBUG
        Serial.println("-->");
        #endif
      }
// ###################### dreht ZURUECK ###########################
      if (merker == 3) { // 1=vor 2=gez 3=rueck 4=erl
        merker = 2; // 1=vor 2=gez 3=rueck 4=erl
        Serial.print("OK VALUES ARDU 1 StromUm=");
        Serial.println("-1");
        #ifdef MY_DEBUG
        Serial.println("<--");
        #endif
      }
      #ifdef MY_DEBUG
      Serial.println("PIN2 on");
      Serial.println(merker);
      #endif
    }
  // ################# 3. Eingang ##################### START ######################
   if ( value3 == HIGH) {
    if (merker != 2 && merker != 3) { // 1=vor 2=gez 3=rueck 4=erl
      merker = 3; // 1=vor 2=gez 3=rueck 4=erl
      #ifdef MY_DEBUG
      Serial.println("PIN3 on");
      Serial.println(merker);
      #endif
    }
    if (merker == 2 ) {
      merker = 4; // 1=vor 2=gez 3=rueck 4=erl
  }
}
}


Beim Stromzähler ist das genau andersherum als beim Wasser- bzw. Gaszähler.
Beim Stomzähler reflektiert die Scheibe ja immer, bis die rote Markierung kommt!

LG
  Marlen

Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 08 September 2017, 23:27:52
ZitatEs gibt übrigens Schwestermodule zu dem von dir genannten ;) . Und für einen "Alarm: Wasserrohrbruch" müßtest du eben ein eigenes notify erfinden

Ja, weiß ich schon, ...den Gascalculator....werd ich wohl auch nehmen. Den kann man auch für Wasser nehmen.
Alarm für Wasserrohrbruch hatte ich jetzt auch schon, muss dann nur das NOTIFY anpassen!

LG
Marlen
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 09 September 2017, 07:40:12
Zitat von: Marlen am 08 September 2017, 22:18:53
Soo .... jetzt schaut es so aus, was sagst du dazu?

WOW! Da hast du große Fortschritte gemacht 8) !

Bei zwei Sachen bin ich mir nicht so ganz sicher:
Das erste verbirgt sich hinter den Stichwort "rollover". Das scheint aber zu klappen, wie du das hast. (Sollte nach 50 Tagen nicht mehr alles gesendet werden, suche nach "millis rollover" und baue es entsprechend um.)
Das andere ist das "L" bei der Berechnung der Sendefrequenz. Damit machst du sie von der Prozessorfrequenz abhängig, was m.E. nicht erforderlich ist, da ja keine wirklich zeitkritische Timing-Berechnung gemacht wird (wäre beim Senden von RF oder IR-Codes was anderes). Und ich kenne das eigentlich nur als Kombination von "UL", habe mich damit aber auch noch nicht intensiver beschäftigt...

Nur für den Fall, dass du noch einen Bewegungsmelder da dranhängen willst: Nutze wenigstens dafür einen interrupt-PIN ::) ...
Und man kann mit einem Arduino auch 1-Wire-Devices auslesen (hat dann aber nichts mehr mit OWX&Co zu tun) ;) und eine ganze Menge anderer Dinge mehr (auf der MySensors-Seite findet sich ja einiges an Sensorik, das man recht einfach auf das keyValueProtocol umbauen kann).

Deine Meinung würde mich jetzt noch interessieren: War für dich das Einarbeiten in die Thematik und das Programmieren des Arduino gefühlt wesentlich schwieriger als das Einarbeiten in Wiring-PI und die Auswertung auf dem PI?
(Klar, es ist "anders", und der Vergleich hinkt immer, da die Vorkenntnisse aus Wiring-PI natürlich auch hier helfen...)

Danke, dass du da dran geblieben bist und das wirklich verstehen wolltest :D .

Eine Bitte noch: neben dem "Gelöst" wäre noch der Hinweis auf das keyValueProtocol im thread-Titel hilfreich. Dann findet ihn ggf. jemand, der ein ähnliches Problem hat, später mal wieder.
Dazu noch eine Frage: Es dürfte reichen, den Arduino als Jeelink einzubinden und dann autocreate anzuschalten, oder?

Gruß, Beta-User
Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Marlen am 09 September 2017, 09:04:23
Ja, bin ganz schön schnell ziemlich weit gekommen!

Was mich als nächstes interessiet:
- wie kann ich einen Ausgang von FHEM aus schalten.
- wie kann ich den arduino per Ethernet bzw. WLAN verbinden.

ZitatDeine Meinung würde mich jetzt noch interessieren: War für dich das Einarbeiten in die Thematik und das Programmieren des Arduino gefühlt wesentlich schwieriger als das Einarbeiten in Wiring-PI und die Auswertung auf dem PI?
(Klar, es ist "anders", und der Vergleich hinkt immer, da die Vorkenntnisse aus Wiring-PI natürlich auch hier helfen...)

Naja, wenn man mal berücksichtigt, das ich diesen Thread vor 3 Tagen eröffnet habe und mich seit dem erst damit beschaffe.....und durch deiner Unterstützung....ging die Einarbeitung schon, hat sich auf jeden Fall geleohnt!

Bin schon auf der suche, wo ich noch einen Arduino einsetzten kann.....aber jetzt muss ich erst mal den Hardwareseitig installieren und dann FHEM umbauen ....

ZitatEine Bitte noch: neben dem "Gelöst" wäre noch der Hinweis auf das keyValueProtocol im thread-Titel hilfreich. Dann findet ihn ggf. jemand, der ein ähnliches Problem hat, später mal wieder.
Dazu noch eine Frage: Es dürfte reichen, den Arduino als Jeelink einzubinden und dann autocreate anzuschalten, oder?

Ja, fand es schon komisch, das es keine Schritt-für-Schritt Anleitung dafür gibt, wie man die Verbindung zu FHEM herstellt!
autocreate muss ich mal testen..

LG und vielen Dank nochmal
   Marlen  :-* :-* :-* :-*




Titel: Antw:GPIO weg vom Raspi --> Arduino
Beitrag von: Beta-User am 09 September 2017, 12:36:46
Zitat von: Marlen am 09 September 2017, 09:04:23
Was mich als nächstes interessiet:
- wie kann ich einen Ausgang von FHEM aus schalten.
- wie kann ich den arduino per Ethernet bzw. WLAN verbinden.
keyValueProtocol ist "one-way" (jedenfalls nach meiner Kenntnis, es gibt aber irgendwo hier auch eine modifizierte Netzwerkversion). ERGO: Schalten mit kvp von FHEM aus geht nicht, Alternativen dann etwas weiter unten...

Eine Darstellung zu Arduino und ähnlichen mcu's (Microcontroller Units) gibt es im Wiki. Hier mal eine etwas "gefärbte Version":

1. M.E. ist es eher eine Notlösung, wenn man einen Arduino (oder ESP8266 etc.) mit einem echten Netzwerkprotokoll in ein Steuerungssystem wie FHEM einbindet. Das bedeutet einen entsprechenden Overhead für die Kommunikation sowie die Abhängigkeit von weiteren Komponenten (Router etc.).
Wenn man das trotzdem unbedingt will:
a) Ethernet: Es gibt entsprechende Shields, damit kann man auch eine serielle Kommunikation innerhalb des Netzwerkprotokolls kapseln.
b) WLAN: auch hier gibt es shields, allerdings ist es in der Regel einfacher, andere mcu's zu nehmen, wobei der ESP8266 die verbreitetste Variante ist. Ich mag diese mcu persönlich überhaupt nicht, und es gibt auch einige technische Gründe, warum man besser die Finger davon läßt. Aber wenn, dann nimmt man z.B. ein Wemos oder eine NodeMCU-Board, damit ist wenigstens das Flashen einfach (sofern man die SW entsprechend vorbereitet hat). WLAN und Batteriebetrieb schließen sich praktisch aus (es gibt einige Spezialisten, die es trotzdem möglich machen, aber da muß man sehr genau wissen, was man tut).

2. Für die Kommunikationsebene finde ich andere Varianten besser:
Dabei wird das, was wir jetzt auf einem Arduino gemacht haben, in der Regel auf zwei verteilt: Einer macht die Kommunikation zum Controller (bei dir: PI mit FHEM, das nennt sich dann Gateway), der andere die eigentliche Meßaufgabe. Dann brauchen beide noch passende Transceiver-Hardware und eine gemeinsame Sprache, um die Daten zu übertragen (Protokoll).
Daher mal ein kurzer Abriss, was da so alles an Protokollen und Transceivern rumschwirrt (ohne Anspruch auf Vollständigkeit):

a) MySensors:
Mögliche Transceiver: nRF24 (2,4 GHz), RFM69 (433&868MHz, Rest ist wohl in D nicht zulässig) und (kabelgebunden, benötigt 2 Adern) RS485
Mein Favorit, einfach auch in der Einbindung in FHEM; nRF und RS485-Tranceiver sind unglaublich billig (ab 40ct pro Stück), allerdings muß man bei Funk ggf. etwas in eine abgesicherte Kommunikation investieren.
Und nochmal zur Klarstellung: Das GW kann auch ein einfacher Arduino Nano mit einer USB-Verbindung sein!

b) AskSin++ - Homematic-Protokoll mit CC1101
Kann auch mit anderen HM-Komponenten sprechen und ist entsprechend abgesichert, erfordert allerdings für die Einbindung in FHEM ein sehr formalisiertes Vorgehen (mein persönlicher Eindruck)
Dafür kann z.B. ein CUL die GW-Aufgabe mit übernehmen...

c) Homebrew-Wired: HM mit RS485 (wie AskSin++, vermutlich etwas einfacher in der Programmierung der Arduinos und  was die Einbindung in FHEM angeht; das GW ist ein fertiger Baustein. Es gibt dazu einen - mindestens vom Lesen her - guten Workshop von T. Pferdekaemper hier im Forum)

d) 433-MHz-Projekte, die die Daten in gängige Protolle kapseln

e) Firmata (USB oder auch über (W)LAN möglich): läßt die direkte Steuerung der IO's von FHEM aus zu, man kann aber praktisch nichts auf der mcu programmieren, aber dafür dann z.B. I2C von FHEM aus steuern (mache ich persönlich lieber mit dem Programm auf den Arduino). Ist etwas "zickig", FHEM mag nicht alle Versionen (insbesondere die neueren nicht). Ist also sowas ähnliches wie der ältere Bruder von ESPEasy.

Mehr fällt mir im Moment nicht ein, aber die Welt da draußen ist groß...

Hoffe, das ist nachvollziehbar.

Gruß, Beta-User
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 09 September 2017, 20:51:57
JETZT weiß ich endlich was du mit kvp meinst!  ;D ;D ;D

Also wenn ich dich richtig verstanden habe, gibt es derzeit keine Möglichkeit in meinen Fall (Arduino per USB am Raspberry) einen Ausgang am Arduino zu schalten??

Zitatb) AskSin++ - Homematic-Protokoll mit CC1101
Kann auch mit anderen HM-Komponenten sprechen und ist entsprechend abgesichert, erfordert allerdings für die Einbindung in FHEM ein sehr formalisiertes Vorgehen (mein persönlicher Eindruck)
Dafür kann z.B. ein CUL die GW-Aufgabe mit übernehmen...

Das hab ich ja schon im Einsatz, dann bräuchte ich praktisch nur noch einen Arduino mit Funkmodul!?

Für was nutzt du eigentlich den Arduino???

LG
  Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 10 September 2017, 07:25:21
Zitat von: Marlen am 09 September 2017, 20:51:57
Also wenn ich dich richtig verstanden habe, gibt es derzeit keine Möglichkeit in meinen Fall (Arduino per USB am Raspberry) einen Ausgang am Arduino zu schalten??
Jein...
ZitatkeyValueProtocol ist "one-way" (jedenfalls nach meiner Kenntnis, es gibt aber irgendwo hier auch eine modifizierte Netzwerkversion). ERGO: Schalten mit kvp von FHEM aus geht nicht, Alternativen dann etwas weiter unten...
Schalten geht schon, nur eben nach meiner Kenntnis nicht mit diesem Protokoll!
Zum einen z.B. mit firmata, was aber den Nachteil hat, dass du Pulse zwar weiterreichen kannst, dafür aber nicht auf dem Arduino selbst irgend eine andere Auswertung machen (also nicht mit dem Sketch aus den 3 Zuständen einen Zählerimpuls ableiten).
Auch als MySensors-GW könntest du PINS ein- und ausschalten, allerdings klappt das Kompilieren mit MySensors nur, wenn auch ein Transceiver definiert ist (angeschlossen muß er nicht sein). Aber damit könntest du dann auch weiter rechnen, kein Problem (warum mag ich MySensors?!?)
Allerdings müßtest du bei einem anderen IO/Protokoll immer auch FHEM-seitig die Dinge anders definieren (bei MySensors würden z.B. 3 Zähler als je eigene ChildID präsentiert, bitte im Wiki den Starter-Guide dazu suchen und lesen, bevor du Fragen dazu stellst). In praktisch jedem anderen Fall  wären die Impulse bzw. Zählerwerte  in einem anderen Reading eines  anderen Device zu finden als jetzt ;) .

Zu AskSin++:
Ja, ein Arduino+Funkmodul würde reichen, ABER:
Die Doku dazu ist - ohne intensive Nachforschung behauptet - in etwa so wie die zum kvp  ::) . Was wann wie zu "verpacken" ist, müsstest du aus vorhandenen Beispielen zusammensuchen, genauso wie die Frage, welche Vorarbeit im FHEM erforderlich ist, um das dann hier einzubinden. Im Ergebnis: Mir persönlich ist das zu viel Einarbeitungsaufwand. Mach' ich vielleicht mal, wenn ich mit anderen Dingen soweit bin...
Ich würde das an deiner Stelle im Auge behalten, wenn die direkte Zusammenarbeit (peering) mit anderen HM Komponenten wichtig wäre und mir vielleicht  mal fertige Projekte ansehen (Fensterkontakt oder Wetterstation). Da siehst du dann auch, wie die Sketche aussehen und welche Chance du hast, da selbst was zu entwickeln.

ZitatFür was nutzt du eigentlich den Arduino???
Interfaces lt. Signatur: Signalduino, 2xMySensors-GW (dazu zwei weitere mcu's: ESP8266 als MiLight-GW und einen Maple-CUN; das ist ein STM32-Arm-Prozessor)
Alle anderen Arduinos sind MySensors-Nodes, an denen eine Vielzahl von Zeugs hängt (in der Regel Multi-Child-Nodes, also mehrere Funktionalitäten pro Arduino), mal auf die Schnelle, was mir so einfällt:
- BME280 (früher mal BMP180)
- 20+ x DS18B20
- Bewegungsmelder bzw. Schwimmerschalter für das Hauswasserwerk bei Tank leer
- Infrarot-Dekoder und Transmitter für den Hifi-Bereich
- Gaszähler (Wasserzähler muß ich die Hardware noch auf Rotlicht umbauen, SW ist aber schon auf der Node)
- Relays bzw. MOSFETS (die On-Zeit für diverse Lichter läßt sich in der Regel von FHEM aus einstellen bzw. teilweise entscheidet der jweilige Arduino, wann ein- und auszuschalten ist (z.B. die Umwälzpumpe für das Warmwasser, wenn eine einstellbare Rücklauftemperatur erreicht ist))
- Servo-Motor (zur Steuerung der 3-stufigen Heizungspumpe, diese Anwendung ist nicht zur Nachahmung empfohlen)

Testweise in Betrieb hatte ich auch schon:
- Lichtsensor (BH1750)
- Digitale Widerstände etc. (MCP4131, MCP4132)

Pipeline:
- Solarbasierte Wetterstation (aus einer China-LED-Lampe) mit
-- BH1750
-- UV (VEML6075)
-- Windgeschw. + -richtung
-- Regenwippe
- Digitale Einbindung meiner Junkers-Therme. Die spricht ein älteres HT3-Protokoll. Ist was "größeres", dafür habe ich daliegen
-- STM32-Platinen, da der Code vermutlich nicht auf einen Nano passen wird
-- CAN-Module (MCP2515)

Bestimmt habe ich noch was vergessen ::) ....

Gruß, Beta-User

Nachtrag: Vergessene Themen:
- Statusdisplay
- RFID
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 12 September 2017, 22:23:27
Sooo, Arduino ist jetzt, auch wenn nur provisorisch im Betrieb und scheint auch gut zu zählen!
Jetzt warte ich mal ein paar Tage, dann vergleiche ich mal die Hardware-Zähler mit den FHEM-Zählern, dann wird sich herausstellen wie gut das ist.

LG
  Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 31 Oktober 2017, 07:37:10
Guten Morgen,

heute war mein Arduino plötzlich DISCONNECTED.......

Ein "set ..... reset" hat auch nix gebracht.

Sogar ein kompletter Neustart des System's hat nix gebracht......

Wie kann man herausfinden was das war und wie verhindern?

LG
  Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 31 Oktober 2017, 07:41:50
Klingt nicht gut.

Kannst du ihn mal an ein Laptop anschließen und z.B. über den seriellen Monitor der Arduino-IDE nachschauen, ob da was ausgespuckt wird?
Oft gibt es sowas wie einen "Startbildschirm", an dem man erkennen kann, ob der Sketch ordentlich startet.
Titel: Antw:[GELÖST] GPIO weg vom Raspi --&gt; Arduino --&gt; Jeelink --&gt; keyValueProtocol
Beitrag von: Marlen am 31 Oktober 2017, 10:04:40
Hab ihn jetzt mal vom RasPi getrennt und wieder eingesteckt, dann war er wieder connected.
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 08:13:50
Du hast doch mal geschrieben:

ZitatBei zwei Sachen bin ich mir nicht so ganz sicher:
Das erste verbirgt sich hinter den Stichwort "rollover". Das scheint aber zu klappen, wie du das hast. (Sollte nach 50 Tagen nicht mehr alles gesendet werden, suche nach "millis rollover" und baue es entsprechend um.)

Meinst du das hatte damit was zu tun?

LG
  Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 08:37:10
Zitat von: Marlen am 03 November 2017, 08:13:50
Meinst du das hatte damit was zu tun?
Schwierig zu beantworten, weil meine Arduinos da eben anderen Code verwenden, von dem ich weiß, dass er funktioniert. Aber nachdem die Zeit bis zum Ausfall ziemlich genau 49.7 Tagen zu entsprechend scheint: Schaden würde es nicht, wenn du den code umbaust.

Aber bei "Disconnected" hätte ich eher an ein anderes Problem gedacht (irgendwas mit dem USB-seriell-Wandler).

Material zum Einlesen: https://arduino.stackexchange.com/questions/12587/how-can-i-handle-the-millis-rollover. Beachte: der Auszug aus dem code dort kommt von http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay (das "Umfeld" dazu muß auch passen).

Viel Erfolg,

Beta-User
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Frank_Huber am 03 November 2017, 09:00:35
Sorry für den Post hier jetzt,

Aber worin liegt jetzt der Vorteil die GPIOs des RasPi durch externe Hardware am RasPi zu ersetzen?
Habe den Sinn von Anfang an nicht verstanden. wofür hat der RPI die GPIOs denn wenn nicht zum benutzen...

just my 2cent....
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 09:24:35
Vorteile nochmal in Kurzfassung:

- 5V statt 3.3V
- Abschirmung des Prozessors vor eventuellen Nutzerfehlern (PI-GPIO sind prozessornah => Zerstörungsgefahr)
- Trennung der Steuerungsschichten, keine spezielle Konfiguration der HW erforderlich => kein Stress mit OS- oder library-updates
- GPIO-Abfragen können den PI (zeitweise) blockieren
- Man braucht als Zentrale nicht zwingend einen PI oder sonst einen SBC=> zukunftssicherer ;)

Etwas weiter gedacht:
Bei "weiter entfernten" Systemen/GPIOs braucht man keinen (wartungsbedürftigen) Rechner für FHEM2FHEM oä., sondern kann mit einfachen Mitteln weitere HW dezentral mit einbinden (MySensors&Co), wenn man "Arduino" uä. mal verstanden hat. Diese Infrastruktur ist zum einen im wesentlichen wartungsfrei und (v.a.) man kann das auch unabhängig von LAN u. WLAN aufbauen. Insbesondere WLAN ist für zentrale Steuerungsaufgaben suboptimal (https://www.youtube.com/watch?v=1JDHWPm-ltY)... Zu WLAN allg. und ESP8266 im besonderen im besonderen hat Hexenmeister jüngst hier noch was nettes (https://forum.fhem.de/index.php/topic,77775.msg707130.html#msg707130) aufgegabelt.

Auch nur my2ct...
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Frank_Huber am 03 November 2017, 10:27:28
Danke Beta-User.

Die Argumente sind alle richtig wenn es um die Entscheidung geht womit ich neu aufbauen will.
Wenn aber ein System mal über GPIO läuft, lohnt dann ein Umbau?

Ich erwarte da keine Antwort, es gibt da wohl auch verschiedene Meinungen.
Nur wenn ich mir anschaue wie viel Aufwand und Nerven es für Marlene waren/ist das umzubauen wäre ich lieber auf GPIO geblieben.
:-)
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 10:52:06
Naja, ich hatte schon Probleme mit den GPIO's als Eingang. Hatte TCRT5000 direkt an den GPIO's und durch den geflacker haben sie für eine erhöhte Systemauslastung gesorgt.

Da ich meine Hardware eh neu strukturiert habe https://forum.fhem.de/index.php/topic,75719.msg693272.html#msg693272 (https://forum.fhem.de/index.php/topic,75719.msg693272.html#msg693272)

war das kein Problem & ich hab was gelernt!

LG
  Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 10:58:39
Zitat von: Marlen am 03 November 2017, 10:52:06
Naja, ich hatte schon Probleme mit den GPIO's als Eingang. Hatte TCRT5000 direkt an den GPIO's und durch den geflacker haben sie für eine erhöhte Systemauslastung gesorgt.

Da ich meine Hardware eh neu strukturiert habe https://forum.fhem.de/index.php/topic,75719.msg693272.html#msg693272 (https://forum.fhem.de/index.php/topic,75719.msg693272.html#msg693272)

war das kein Problem & ich hab was gelernt!

LG
  Marlen

Danke für die Rückmeldung!

Auch ohne Erwartung noch ein paar allgemeine Anmerkungen @Frank_Huber:

Ein funktionierendes (und auch rund laufendes) System umzubauen, würde ich auch nicht angehen, zumal du ja entsprechende IO-Boards drauf hast, das dürfte das elektrische Problem etwas entschärfen.

Aber bei jeder Änderung bzw. jedem Umbau, der "eh" ansteht, würde ich mir das überlegen. Auch, weil man damit (genau abgrenzbare) Teile der Intelligenz auslagern kann (ähnlich der rules bei ESPEasy), was dafür sorgt, dass Dinge auch ohne FHEM funktionieren.

Und was den Aufwand angeht, "Arduino " zu lernen: Das muß jeder selbst entscheiden... Wohlgemerkt: in diesem Fall war der Weg "mehrfach speziell" (Zählerlogik an sich und gewähltes Protokoll). Mit MySensors als Protokoll wären wir deutlich schneller gewesen...
Für einen wirklichen Neuling dürfte der Gesamtaufwand, sich in Arduino einzudenken kaum anders sein, als den PI-GPIO-Kram zu konfigurieren.

Ich bin jedenfalls froh, dass ich mir als erstes mal mit GPIO-Spielereien einen PI abgeschossen habe und seitdem die Finger davon lasse. Damit bin ich mit der Server-Hardware nicht auf PI, Banane oder ähnlichem angewiesen, und das bei nur unwesentlichem Mehrverbrauch (wenn überhaupt).

;D 8) ;D
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 11:08:46
Was ist der Unterschied zu MySensors?
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 11:21:15
MySensors
- kenne ich (im Gegensatz zu kvp), kann also eher helfen ;)
- ist bidirektional, man kann also auch schalten, Konfigurationsdaten uä. an die Arduininos senden oder ACK's anfordern (Rückmeldung, ob ein Befehl oder eine Sensor-Info angekommen ist)
- ist in der Einbindung in FHEM m.E. einfacher, weil man direkt den Typ der übermittelten Information (einmalig) festlegt. Ein als Zähler gemeldeter Sensortyp wird in MySensors gleich als solcher angelegt usw., man muß nix weiter konfigurieren.

Ansonsten ist es ähnlich, man kann insbesondere allen Arduino-Code (und alle Sensor-Hardware, für die es eine lib gibt) reicht einfach verwenden bzw. einbinden und entsprechende Programme selbst schreiben, Sensoriken kombinieren usw.. Bis halt der Speicher aus ist (dann kann man aber auch andere mcu's verwenden und weitermachen ;) ).
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 11:38:33
Und die Programmierung erfolgt mit der selben Software?
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 11:50:08
Es ist nach wie vor ein Arduino, auch wenn eine weitere lib namens MySensors benutzt wird... Also: Klar doch!

Wenn du Gefallen daran hast, würde ich mir auch mal Atom mit PlattformIO ansehen. Ich kenne das zwar (noch) nicht, die Editor-Funktionen scheinen aber deutlich besser zu sein als die Schmalspur-Version, die die Arduino-IDE mitbringt. Damit sollte man auch flash-Befehle uw. absetzen können.

Gelegentlich nutze ich als reinen Editor zum Erstellen/Bearbeiten der Sketches auch notepad++. Zum flashen muß der Sketch dann in dem Fall aber wieder in die Arduino-IDE geladen werden (oder ein anderes Tool, das das flashen beherrscht).
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 11:55:06
Aha...und gibt es einen Arduino  mit WLAN-on-Board?
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 12:20:56
Jein, es gibt zwar von Arduino.cc wohl auch ein Board, auf dem ein WLAN-Chip verbaut ist (ohne Gewähr: Yun oder so).

Aber das lohnt m.E. nicht für "unsere" Art Projekte. Wenn WLAN (wovon ich nach wie vor dringend abraten würde (!)), dann ein ESP. Z.B. den ESP8266 kann man auch mit der IDE programmieren, wenn man die dafür erforderlichen Tools mit einbindet. Für die ESP's ist aber vermutlich ESPEasy einfacher zu verwenden.

MySensors nutzt aber für eine eventuelle Funk-Strecke 2.4GHz (nRF24L+) oder 868MHz bzw. 433MHz (RFM69), man braucht also keine Netzwerktechnik im Hintergrund (kann aber ein WiFi-GW auf Basis eines ESP8266 aufbauen, das ist aber optional (!)). Die einfachste Variante sind 1 Arduino Nano als serielles GW (mit einem der beiden genannten Transceiver) und ein (oder mehrere) weiterer(e) Arduinos (Nano, pro mini (oder andere mcu's) jeder mit einem weiteren Transceiver)...
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 19:55:40
Nochmal, weil mein Arduion plötzlich nicht mehr gesendet hat.
Du hast ja geschrieben:
ZitatDas erste verbirgt sich hinter den Stichwort "rollover". Das scheint aber zu klappen, wie du das hast. (Sollte nach 50 Tagen nicht mehr alles gesendet werden, suche nach "millis rollover" und baue es entsprechend um.)

Erst mal würde mich mal interessieren, warum das nach 50 auftritt.
Und dann müsste ich hier was ändern!?

if ( millis() - lastRun >= INTERVAL ) {
   Spannung();
   senden();
   merkerk = 0;
   lastRun += INTERVAL;
}


LG
Marlen
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 19:59:24
Ahhh.....

https://www.arduino.cc/en/Reference/Millis (https://www.arduino.cc/en/Reference/Millis)
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 20:33:38
Andrerseits, wenn millis nach 50 Tagen wieder bei 0 beginnt, hätte ja mein Stromzähler weiter übermittelt werden müssen, der wird ja gesendet pro impuls.

Außerdem war der Arduino ja in FHEM disconnected.

Aber nach 50 Tagen hab ich auch ein Problem!?

Kann man millis auch selbst setzen?
z.B. so:

if ( millis() >= 600000000 ) { //###### ca. 7 Tage
   millis = 0;
   lastRun = INTERVAL;
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 22:15:40
Wie bereits gesagt: Ich halte es auch nicht für wahrscheinlich, dass es das millis()-rollover-Problem war, da disconnected. Wenn FTDI: Test-PIN ist auf Ground?

Und dein Code sieht soweit ok aus, vorausgesetzt, INTERVAL und lastrun sind vom richtigen Datentyp,-
Ein reset von millis() ist - soweit mir bekannt - nicht möglich (und auch nicht erforderlich, wie bei den verlinkten Beiträgen auf Arduino.cc ausgeführt).
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 03 November 2017, 23:01:21
const unsigned long INTERVAL = 1000L*60* 1; // ############## 1 Minuten
unsigned long lastRun = 0 ;
.... passt, oder?

Nach den Test-Pin schau ich morgen mal!
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Beta-User am 03 November 2017, 23:26:51
Zitat von: Marlen am 03 November 2017, 23:01:21
.... passt, oder?
Ja.
Scheint also irgend was anderes gewesen zu sein, wobei das mit dem Test-PIN "nur" dazu führt, dass ein Reboot vom PI nicht sauber ausgelöst wird. Weitere Disconnects müßte man dann SW-seitig (mit FHEM) abfangen.
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Freibeuter am 30 April 2019, 15:43:13
Hallo Marlen,
hast du drei TCRT5000 auf deinem Stromzähler montiert ?
Welchen Arduino hast Du genommen, der Nano hat ja nur 2 Interrupts?
Gruß
Der Freibeuter
Titel: Antw:[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol
Beitrag von: Marlen am 06 Mai 2019, 12:12:37
hallo,

habe einen Nano 3.0 ATMEGA328P FT232RL genommen.

Ja, ich habe 3 TCTR5000 für den Stromzähler und je einen für Gas und Wasser.

LG
  Marlen