[GELÖST] GPIO weg vom Raspi --> Arduino --> Jeelink --> keyValueProtocol

Begonnen von Marlen, 06 September 2017, 07:50:07

Vorheriges Thema - Nächstes Thema

Marlen

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

Beta-User

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 (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 ).
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

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

Beta-User

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 ;) .
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

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" ???

Beta-User

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 :-*
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

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

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

Naja, so halt
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 .......;

Beta-User

Zitat von: Marlen am 08 September 2017, 12:37:10
Naja, so halt
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...
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...

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 so.....
dann einfach zum testen am PC
so define MY_DEBUG
und
vor dem Hochladen so:
//define MY_DEBUG
???

Beta-User

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.
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

O.k. dann kann ich heute Nacht wieder was machen!  ;)

Danke!  :-*

Marlen

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!

Beta-User

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)
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