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

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

Vorheriges Thema - Nächstes Thema

Frank_Huber

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

Marlen

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

war das kein Problem & ich hab was gelernt!

LG
  Marlen

Beta-User

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

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


Beta-User

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


Beta-User

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


Beta-User

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

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


Marlen

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;

Beta-User

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

const unsigned long INTERVAL = 1000L*60* 1; // ############## 1 Minuten
unsigned long lastRun = 0 ;
.... passt, oder?

Nach den Test-Pin schau ich morgen mal!

Beta-User

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