Eigene Sensoren -> Grundlegende Hardware

Begonnen von DerFrickler, 01 August 2017, 10:30:31

Vorheriges Thema - Nächstes Thema

DerFrickler

Ich habe aktuell NRF24L01+ PA LNA im Einsatz, werde später auch noch RFM69 (433 MHz) testen, die 868Mhz sind noch auf dem Weg. Diejenigen, mit denen ich dann am besten auskommen werde, werden dann auch final in allen Sensoren verbaut.

Beta-User

Für die nRF habe ich gute Erfahrungen mit den in der Bucht erhältlichen Adapter-Boards gemacht, da sind auch Kondensatoren mit drauf. PA+LNA direkt am 3.3V-PIN ist eher nicht zu empfehlen.

Mit den anderen Bausteine habe ich keine Erfahrung.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

auf mysensors.org werden explizit der Pro Mini und der Nano genannt, wenn ich jetzt aus dem Uno ein Gateway machen möchte benötige ich keinen adapter und kann den nrf24 direkt an 3,3 V anschliessen?

Beta-User

Hat der Uno einen anderen Spannungswandler drauf?

Du kannst Du es ja versuchen, ggf. mit einer Änderung auf PA_LOW oder MIN. Gerade für die PA+LNA-Module sollte aber eine stabile Spannungsversorgung hohe Prio haben. Also: wenn's nicht klappt, nicht wundern und nachbessern, Du weißt ja wo suchen... ;)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Den Uno habe ich mit dem Adapter getestet, leider habe ich ein Problem mit dem Ethernet Shield (https://forum.fhem.de/index.php?topic=75253.0). Um weiter zu kommen, habe ich den Raspberry GW ans Laufen gebracht (auch mit Adapter). Als Sensor habe ich den UV-Sensor gebaut. Da die Sonne aber eher selten im Arbeitszimmer scheint und es aktuell regnet dürfte für das Senden aktuell eher die 5-Minuten Regel greifen, doch sie tut es nicht...

unsigned long lastSend =0;
...
    unsigned long currentTime = millis();
...
    //Send value to gateway if changed, or at least every 5 minutes
    if ((uvIndex != lastUV)||(currentTime-lastSend >= 5UL*60UL*1000UL)) {
        lastSend=currentTime;
        send(uvMsg.set(uvIndex,2));
        lastUV = uvIndex;
    }


Ich habe mir das ganze mal auf der Konsole ausgeben lassen, mit folgendem Ergebnis:

1. Zyklus:
currentTime: 2191
lastSend: 0

Differenz: 2191
Der Vergleichswert beträgt: 300000

2. Zyklus:
currentTime: 2213
lastSend: 2191

Differenz: 22
Der Vergleichswert beträgt: 300000

Irgendwie werde ich das Gefühl nicht los dass currentTime gar nicht in Millisekunden gemessen wird, trotz der Angabe millis()??

Ich hoffe von Euch kann mir da jemand weiterhelfen.

Danke!

Beta-User

Das mit currentTime sollte an sich schon passen, aber insgesamt kommt es mir so vor, als wäre die Logik nicht ganz optimal:

- Du mißt bei jedem loop()-Durchlauf? Warum? Jede Minute (oder sogar länger) sollte doch reichen. Ich würde erst mal hart alle 20 Sek. senden und erweiterte Logik an der Stelle später einfügen.
- Da lastSend einen update bekommt, müßte auch was gesendet worden sein. Da wäre eher die Frage, warum das GW das nicht mitbekommt. Ich würde auf ein Problem mit dem GW tippen.

Was spuckt #MY_DEBUG an der Konsole des Sensors aus? Was passiert, wenn Du ein "Ack" anforderst? (Ohne Gewähr:
"send(uvMsg.set(uvIndex,2), true)")

Es kommt mir so vor, als wolltest Du zu viel auf einmal...

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

Beta-User

Ergänzung noch:

- Die Node ist bereits angelegt?
- Hast Du mal versucht, erst mal den Arduino als GW zu nutzen (nur GW-Feature aktivieren, das reicht schon...). Das mit dem PI ist für Fortgeschrittene
- Du nutzt doch hoffentlich 2.2.0-beta; ohne das geht es vermutlich gar nicht  ;)

Wenn Dir die Arduinos ausgehen: Sag per pm Bescheid, notfalls kann ich Dir ein, zwei in einen Umschlag stecken.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Zitat von: Beta-User am 10 August 2017, 16:24:12
Das mit currentTime sollte an sich schon passen, aber insgesamt kommt es mir so vor, als wäre die Logik nicht ganz optimal:

- Du mißt bei jedem loop()-Durchlauf? Warum? Jede Minute (oder sogar länger) sollte doch reichen. Ich würde erst mal hart alle 20 Sek. senden und erweiterte Logik an der Stelle später einfügen.
- Da lastSend einen update bekommt, müßte auch was gesendet worden sein. Da wäre eher die Frage, warum das GW das nicht mitbekommt. Ich würde auf ein Problem mit dem GW tippen.

Was spuckt #MY_DEBUG an der Konsole des Sensors aus? Was passiert, wenn Du ein "Ack" anforderst? (Ohne Gewähr:
"send(uvMsg.set(uvIndex,2), true)")

Es kommt mir so vor, als wolltest Du zu viel auf einmal...

Gruß, Beta-User

Es handelt sich bei dem Sketch um das Beispiel von mysensors. Nehme ich die if-Abfrage raus, dann wird alle 30 Sekunden eine Message versendet. Funktioniert alles wunderbar, veränderte UV-Werte werde ich dann nach dem Dauerregen testen. Die 30 Sekunden kommen von dem sleep(SLEEP_TIME).

Das einzige Problem ist folgende Zeile:

    if ((uvIndex != lastUV)||(currentTime-lastSend >= 5UL*60UL*1000UL)) {

wenn sich der UV-Index nicht ändert. Das mit den 5-Minuten haut nicht hin, da bei mir currentTime sowie lastSend nicht in Millisekunden gemessen wird, sondern was ganz anderes.


DerFrickler

Zitat von: Beta-User am 10 August 2017, 16:33:56
Ergänzung noch:

- Die Node ist bereits angelegt?
PI-GW läuft sauber und UV-Sensor ist aktiv.

- Hast Du mal versucht, erst mal den Arduino als GW zu nutzen (nur GW-Feature aktivieren, das reicht schon...). Das mit dem PI ist für Fortgeschrittene
Der Arduino GW macht Probleme, da es allem Anschein nach 2 Widerstände im Ethernet Shield einzulösen gilt.

- Du nutzt doch hoffentlich 2.2.0-beta; ohne das geht es vermutlich gar nicht  ;)
Du sprichst hier von der mysensors Version?

Wenn Dir die Arduinos ausgehen: Sag per pm Bescheid, notfalls kann ich Dir ein, zwei in einen Umschlag stecken.
Das dürfte in naher Zukunft nicht passieren

Beta-User

OK, die Kommunikation zwischen GW und node passt also, dann dürfte dei MySensors-lib-Version auch 2.2.0-beta sein.

Das mit dem Ethernet-Shield verstehe ich (nicht), es gibt auch ein ganz ordinäres serielles GW, anzuschließen via USB. Das meinte ich (ist aber egal, da GW und Node miteinander sprechen).

Dein Problem dürfte folgendes sein: Du machst ein sleep(). Das setzt nach meiner Kenntnis millis() zurück...

Meine Arduinos behalte ich auch gerne, sonst muß ich nur nachbestellen und Chinesen verhauen, wenn sie mir fake TFDI's unterschieben wollen :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Zitat von: Beta-User am 10 August 2017, 16:46:22
OK, die Kommunikation zwischen GW und node passt also, dann dürfte dei MySensors-lib-Version auch 2.2.0-beta sein.
Laut Bibliotheksverwalter ist die Version 2.1.1 installiert, die Möglichkeit eine Beta-Version zu installieren kann ich im Verwalter nicht finden. Muss ich dazu spezielle Einstellungen vornehmen?
Das mit dem Ethernet-Shield verstehe ich (nicht), es gibt auch ein ganz ordinäres serielles GW, anzuschließen via USB. Das meinte ich (ist aber egal, da GW und Node miteinander sprechen).
Möglicherweise führt ja auch ein Update der lib-Version zum Erfolg, deshalb auch meine Frage im anderen Beitrag.... bevor ich das Shield unnötig zerstöre.
Dein Problem dürfte folgendes sein: Du machst ein sleep(). Das setzt nach meiner Kenntnis millis() zurück...
Das sollte doch sicherlich auch anderen Foren Mitgliedern aufgefallen sein, insbesondere da es ja original Beispiel-Sketch ist.
Meine Arduinos behalte ich auch gerne, sonst muß ich nur nachbestellen und Chinesen verhauen, wenn sie mir fake TFDI's unterschieben wollen :) .

Beta-User

Was den Sketch angeht: Welchen genau hast Du verwendet? Bitte einen Link oder den code direkt.
Ich habe mal hier nachgesehen, da wird nur sleep() verwendet, nicht noch parallel millis(). Was bei Dir Probleme zu machen scheint, ist die Kombination beider Methoden.

Die Beta-Version habe ich über git installiert.
Dazu reicht es, in dem Ordner, in dem die Arduino-libraries liegen ein git clone ... auf das MySensors-Github-repo zu machen, dann kann man auch die Versionen wechseln (git checkout...). Evtl. liege ich auch falsch, ich bin irgendwie davon ausgegangen, dass es um RFM69-Module geht, und da war 2.2.0-beta als Empfehlung für ein PI-GW auf der offiziellen Seite genannt (bei build, meine ich).

Was das Serielle GW angeht: Ich kann hier nirgendwo einen Netzwerkshield erkennen: https://www.mysensors.org/build/serial_gateway. Wir sprechen also über unterschiedliche Dinge. Ich nur über einen Arduino, der nicht mal ein Funkmodul braucht, geschweige denn Netzwerk.
Und wenn der Netzwerkshield mit den falschen Widerständen ausgestattet ist, helfen m.E. neue libs tendenziell eher nichts, zumal es eher Ausnahmen zu sein scheinen, bei denen falsche Widerstände verwendet wurden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Zitat von: Beta-User am 10 August 2017, 17:08:04
Was den Sketch angeht: Welchen genau hast Du verwendet? Bitte einen Link oder den code direkt.
Ich habe mal hier nachgesehen, da wird nur sleep() verwendet, nicht noch parallel millis(). Was bei Dir Probleme zu machen scheint, ist die Kombination beider Methoden.
https://www.mysensors.org/build/uv


Beta-User

Asche auf mein Haupt, ich hatte nur nach dem VEML gesucht, weil ich irgendwie der Ansicht war, das sei der Sensor, den Du nutzt :( .

Aber @sundberg84 sagt in der Diskussion zu dem Beispiel weiter unten auch in einem Nebensatz:
ZitatAlso, do you run this on batteries and sleep the node the 5 min delay wont work and you have to remove it.

Also nochmal: sleep() und millis() vertragen sich nicht, das wird so nicht funktionieren.
Quellen: https://arduino.stackexchange.com/questions/30077/how-to-keep-accurate-millis-while-using-adc-sleep-mode
https://forum.mysensors.org/topic/7263/remainder-sleep-time-upon-an-interrupt/5

Ergo: entweder aus dem sleep() ein wait() machen (dann aber kein Batteriebetrieb), oder einen Rundenzähler einführen, und dann nur alle 10 Runden senden und den Zähler zurücksetzen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DerFrickler

Zitat von: Beta-User am 10 August 2017, 17:49:40
Asche auf mein Haupt, ich hatte nur nach dem VEML gesucht, weil ich irgendwie der Ansicht war, das sei der Sensor, den Du nutzt :( .

Aber @sundberg84 sagt in der Diskussion zu dem Beispiel weiter unten auch in einem Nebensatz:
Also nochmal: sleep() und millis() vertragen sich nicht, das wird so nicht funktionieren.
Quellen: https://arduino.stackexchange.com/questions/30077/how-to-keep-accurate-millis-while-using-adc-sleep-mode
https://forum.mysensors.org/topic/7263/remainder-sleep-time-upon-an-interrupt/5

Ergo: entweder aus dem sleep() ein wait() machen (dann aber kein Batteriebetrieb), oder einen Rundenzähler einführen, und dann nur alle 10 Runden senden und den Zähler zurücksetzen.
Na jetzt mal locker bleiben, Du hast mir den Einstieg schon sehr erleichtert. Immerhin habe ich jetzt den Gateway (Pi + Ethernet) sowie einen UV-Sensor und einen Staubsensor im Einsatz, weitere folgen. Das Problem mit dem sleep und den millis werde ich schon noch irgendwie gelöst bekommen.
Beim UV-Sensor wird ohne Wertänderung alle 5-Minuten trotzdem gesendet (so der Plan).
Beim Staubsensor nur bei Wertänderung.
Die Variante mit den 5-Minuten gefällt mir und ich werde mal sehen wie sich das Problem lösen lässt. Immerhin gibt mit currentTime ja einen Wert zurück, mal sehen was sich damit machen lässt. Die Beispiele sind gut, meistens sogar ausreichend... können aber auch angepasst werden.