diverse Sensoren an FHEM anbinden OHNE Funk

Begonnen von flipse, 03 Juli 2019, 08:34:32

Vorheriges Thema - Nächstes Thema

flipse

Hallo zusammen,

derzeit habe ich diverse Reedkontakte (Garage, Türen etc.) per Fibaro Universalsensor über ZWave an FHEM angebunden.
Soweit so gut. Nun liegen die Universalsensoren direkt neben dem NAS mit dem ZWave Empfänger. Und weitere Sensoren sollen auch noch dazukommen.

Ich möchte gerne diese Funklösung, wo sie nicht zwingend notwendig ist, eliminieren.

Wie kann ich diese Türkontakte, Reedsensoren etc. an mein NAS am besten per USB, anschließen?

Vielen Dank schon mal für Eure Hilfe

Beta-User

Hmm, also: Du hast bereits Kabel von den Reed-Kontakten zum Server liegen, wenn ich das richtig verstanden habe?

Dann sollten eigentlich alle gängigen Optionen funktionieren, du brauchst ja kein Bussystem und auch keine "besondere Logik", um die Kontakte abzufragen...

Ist also eher eine Frage der Einarbeitung, des Budgets usw..

Meiden würde ich Pi-GPIO's, aber ansonsten käme v.a. 1-wire oder diverse Arduino-Lösungen wie HomeBrewWired, Firmata und MySensors in Frage; ich selbst würde das mit MySensors lösen, dürfte nicht besonders aufwändig sein, auch von der Programmierung (wäre ein Multi-Button-Sketch, der eben eine ganze Anzahl von Bewegungsmeldern bzw. Tür/Fensterkontakten vereint).Bei Interesse an dieser Lösung kann ich gerne zu unterstützen versuchen, du bräuchtest aber einen Arduino (wenn alle Kabel an einer Stelle zusammenlaufen, reicht ausnahmsweise einer auf für MySensors). Nano wäre ohne Erweiterungshardware für ein gutes Dutzend Kontakte tauglich; wenn du mehr brauchst: evtl. "größeres Board". Dabei beachten: mehrere der China-Clone sind über USB direkt schwerer zu handeln, das sollten dann welche mit FTDI-USB-Seriell-Wandler sein (das gilt für alle Arduino-Lösungen!).
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

flipse

Ja, die Kabel liegen alle beim Server.
Jetzt ist wirklich die Frage, was für Möglichkeiten der "Hartverdrahtung" gibt es und welche Vor-/Nachteile haben diese.

Ich präferiere hier eine schlanke, energiesparende Lösung ;)

Beta-User

...viel weniger Energie als ein Arduino Nano wird auch jede andere Lösung nicht benötigen...
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


Beta-User

Prinzipiell ja, aber sobald du mehr wie einen am selben Linux-Rechner anschließt, ist die USB-ID nicht mehr eindeutig. Das ist die Einschränkung hinter "kompatibel"...

Der hier scheint z.B. einen "richtigen" FTDI zu nutzen (kenne den Lieferanten nicht, war nur auf die Schnelle recherchiert/überflogen):
https://www.amazon.de/AptoFun-Org-ATmega328P-FT232RL-Development-kompatibel/dp/B014TE52RS/ref=sr_1_7?keywords=arduino+nano+ftdi&qid=1562151753&s=gateway&sr=8-7

Zur Info: Lieferungen aus China kosten für "echte" ca. 4 Euro, dauern aber länger...

Eine Garantie, dass es kein Fake-FTDI ist, hast du praktisch nur, wenn du einen Originalen Nano von der arduino-foundation kaufst oder einem der großen E-Distributoren...
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

Meck

Hallo,

ich persönlich würde auf die MySensor Lösung setzen, da diese sehr offen ist um deine Ganzen Geräte Zentral und dezentral zu erfassen und ein LAN Gateway verwenden, da hierdurch der USB Port von der NAS Freibleibt.


Zitat von: Beta-User am 03 Juli 2019, 13:07:29
Eine Garantie, dass es kein Fake-FTDI ist, hast du praktisch nur, wenn du einen Originalen Nano von der arduino-foundation kaufst oder einem der großen E-Distributoren...

Schaut man sich etwas um, findet man aber genug aus China mit einem FTDI-Chip. Wenn er auf ein Lan Gateway geht, sollte der Chiptyp keine Rolle spielen.

Gruß

Meck

Beta-User

Na ja, erst ins Lan gehen, wenn direkt daneben der Server steht?

Was fakes angeht: Ich habe mind. schon 2 (aus zwei Handvoll) in der Hand gehabt, die angeblich FTDI waren. Einer davon war in einer Lieferung mit zweien, kam also zum selben Zeitpunkt aus derselben Quelle. Man kann das z.B. dadurch versuchen zu verifizieren, dass man z.B. die Serial oder den Produktnamen ändert (ich mache das mit einem Linux-Tool, FTDI bietet auch direkt ein Programm für Windo.*).

Sowas mit "Achtung, fakes im Umlauf" erwähne ich in der Regel nicht ganz ohne Grund...
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

flipse

#8
Zitat von: Meck am 05 Juli 2019, 13:08:57
Hallo,

ich persönlich würde auf die MySensor Lösung setzen, da diese sehr offen ist um deine Ganzen Geräte Zentral und dezentral zu erfassen und ein LAN Gateway verwenden, da hierdurch der USB Port von der NAS Freibleibt.


Schaut man sich etwas um, findet man aber genug aus China mit einem FTDI-Chip. Wenn er auf ein Lan Gateway geht, sollte der Chiptyp keine Rolle spielen.

Gruß

Meck

ich bekomme heute wohl meinen Arduino und bin schon ganz gespannt zu testen.
Im ersten Step möchte ich gerne meine Türkontakte einbinden.
Diese würde ich erstmal, bevor ich mein bestehendes System umziehe, simulieren durch eine entsprechende Verkabelung.

Als Einsteiger: Womit sollte man, der Einfachheit halber einsteigen, wenn man das ERgebnis der Digitalen Inputs an FHEM weiterleiten will?
Firmata oder MySensors?

Mein Vorgehen  wäre wie folgt:

1) Arduino IDE installieren
2) FW / Sketch installieren
3) Im Serialmonitor prüfen, ob die PINS ankommen
4) Arduino per USB an NAS anschließen
5) Arduino an VM "durchschleifen"
6) Arduino in FHEM anlegen und prüfen, ob connected
7) Die jeweiligen Eingänge (als Devices in FHEM) anlegen

Tutorials habe ich in der Form nicht gefunden, außer das, was man sich hier aus dem Forum zusammensammeln kann, oder?

Meine Anforderungen:
- Mehrere Türkontakte an Digitale Inputs anschließen und an FHEM durchrouten (ohne vorherige Datenmanipulation)
- Perspektivisch Zähler für Wasser und Strom einbinden (in regelmäßigen Abständen melden, ggf. über den DS2423 als 1-Wire?)

Beta-User

Zitat von: flipse am 05 Juli 2019, 13:31:47
Als Einsteiger: Womit sollte man, der Einfachheit halber einsteigen, wenn man das ERgebnis der Digitalen Inputs an FHEM weiterleiten will?
Firmata oder MySensors?
Nach meinem Verständnis:
keyValueProtocol...

(Ich habe u.a. https://wiki.fhem.de/wiki/MySensors_Starter_Guide verfaßt, und kann dir gerne auch MySensors erläutern ;) ).
Firmata kenne ich nur dem Namen nach, denke aber, dass es weniger geeignet ist, weil es die Auswertung der Pin-Zustände selbst auf den Server verlagert; das kann man mit den beiden anderen Lösungen mMn. direkter auf dem Arduino lösen.

Ich würde erst mal mit den Kontakten anfangen, da aber bitte die Pins 2+3 freihalten (die sind für Zählaufgaben besser geeignet).

Wenn du Grundlagen der Programmierung kennst, würde ich als Grundlage für den keyValueProtocol-Sketch den im MySensors-Bereich (hier im Forum) bei den "Muster-Lösungen" verlinkten Multi-Button-Relay-Sketch nehmen (der hat nur den gewaltigen Nachteil, dass dort der Code direkt eine Verbindung zwischen Taster und Relais herstellt; das brauchst du nicht, diese Teile müßten also raus...)
Oder du schaust dir mal an, ob in der bounce2()-Bibliothek ein Beispielsketch drin ist, der sollte dann auch direkt was in die Konsole werfen (das müßtest du für keyValueProtokoll nur geringfügig umbauen).
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

flipse

#10
Zitat von: Beta-User am 05 Juli 2019, 14:05:38
Nach meinem Verständnis:
keyValueProtocol...

(Ich habe u.a. https://wiki.fhem.de/wiki/MySensors_Starter_Guide verfaßt, und kann dir gerne auch MySensors erläutern ;) ).
Firmata kenne ich nur dem Namen nach, denke aber, dass es weniger geeignet ist, weil es die Auswertung der Pin-Zustände selbst auf den Server verlagert; das kann man mit den beiden anderen Lösungen mMn. direkter auf dem Arduino lösen.

Ich würde erst mal mit den Kontakten anfangen, da aber bitte die Pins 2+3 freihalten (die sind für Zählaufgaben besser geeignet).

Wenn du Grundlagen der Programmierung kennst, würde ich als Grundlage für den keyValueProtocol-Sketch den im MySensors-Bereich (hier im Forum) bei den "Muster-Lösungen" verlinkten Multi-Button-Relay-Sketch nehmen (der hat nur den gewaltigen Nachteil, dass dort der Code direkt eine Verbindung zwischen Taster und Relais herstellt; das brauchst du nicht, diese Teile müßten also raus...)
Oder du schaust dir mal an, ob in der bounce2()-Bibliothek ein Beispielsketch drin ist, der sollte dann auch direkt was in die Konsole werfen (das müßtest du für keyValueProtokoll nur geringfügig umbauen).

Die Grundlagen der Programmierung sind mir denke ich bekannt. Bin aber eher im .NET Framework mit C# unterwegs. Oder eben Webseiten mit PHP.
Diese Arduino Programmierung sieht für mich ein wenig aus wie java...

Du sagst also, es ist besser, die Verarbeitung auf dem Arduino durchzuführen und dann an FHEM zu senden?
Kann FHEM denn dann noch aktiv einen Status abfragen? (PULL) oder muss FHEM immer warten, bis der Arduino eine Statusänderung meldet (bzw. zyklisch den Status schickt?)

Zum keyvalue hatte ich hier schon etwas gelesen, da hattest Du Marlene geholfen, ihre Zähler über Arduino zu realisieren.
Heißt dass, dass ich eine ConsolenAusgabe des Arudinos nach einer bestimmten Syntax durchführe und FHEM diese dann entgegennimmt?

Beta-User

FHEM wartet dann einfach, bis was geliefert wird. Kann man natürlich zyklisch machen (und würde ich für einen Zähler auch so implementieren, iVm. einem Interrupt-Handler auf je Pin 2 und 3); Stichwort wäre dann millis() (ist wohl unter "non-blocking loop" zu finden).

Mit dem "einfachen Lauschen" habe ich @MySensors eigentlich nur gute Erfahrungen gemacht. Das in Verbindung mit einem "heartbeat" reicht mMn. völlig, man braucht kein Pollen.

Satus von Tastern/Schaltern: tendenziell nur beim Starten und bei Änderung, aber eine optionale "get-Routine" einzubauen, wäre @MySensors gar kein Thema (würde dann aber alle Pins melden)...

"Arduino" ist afaik im Prinzip C/C++.
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

flipse

Zitat von: Beta-User am 05 Juli 2019, 14:51:53
FHEM wartet dann einfach, bis was geliefert wird. Kann man natürlich zyklisch machen (und würde ich für einen Zähler auch so implementieren, iVm. einem Interrupt-Handler auf je Pin 2 und 3); Stichwort wäre dann millis() (ist wohl unter "non-blocking loop" zu finden).

Mit dem "einfachen Lauschen" habe ich @MySensors eigentlich nur gute Erfahrungen gemacht. Das in Verbindung mit einem "heartbeat" reicht mMn. völlig, man braucht kein Pollen.

Satus von Tastern/Schaltern: tendenziell nur beim Starten und bei Änderung, aber eine optionale "get-Routine" einzubauen, wäre @MySensors gar kein Thema (würde dann aber alle Pins melden)...

"Arduino" ist afaik im Prinzip C/C++.

Das klingt gut. Ich würde wirklich noch versuchen eine getRoutine einzubinden (ist dann wahrscheinlich eine Methode im Sketch, die von FHEM angetriggert wird), damit aktiv die Stati abgefragt werden.


Das Thema Heartbeat ist auch irgendwo beschrieben?

Ich bin auch eher der Fan vom Push, dann werden auch nur notwendige Daten übertragen und entsprechender Traffic generiert.

Beta-User

Also:

Wenn du ein "get"-ähnliches Verhalten haben willst, bist du tendenziell bei MySensors. Da muß ich zugeben, das ich bisher immer einen "Transport" definiert hatte - hier haben wir es mit einem GW-only zu tun, das sollte aber auch kein Problem sein.

@MySensors gibt es im Sketch dann eine Receive-Funktion, in der man dann noch auswerten kann, welcher "Endpunkt" genau gemeint ist usw.. Am einfachsten mal die Beispielsketche bei MySensors.org (/build?) durchsehen, dort z.B. einen Relay- oder Servo-Sketch (oder den zitierten Multi-Button/Relay suchen).

Heartbeat fordert das FHEM-IO-Modul bei einem GW automatisch an, ansonsten mal die cref zu MYSENSORS_DEVICE zu Rate ziehen (oder was ich dazu bei den letzten Änderungen geschrieben hatte).
Bei normalen Nodes ist es im Prinzip eine millis()-getriggerte einzeilige Anweisung im Sketch iVm. einem Attribut am MYSENSORS_DEVICE in FHEM... "Im Prinzip" auch easy.
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

flipse

#14
Hi,

ich habe nun diverse Beispiel-Sketches angeschaut und versucht selbst etwas zu programmieren, aber ich habe noch Startschwierigkeiten mit Arduino IDE.
Ich bekomme immer beim Hochladen mit Programmer eine Fehlermeldung, die leider nicht aussagekräftig ist:

Der Sketch verwendet 13676 Bytes (44%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 449 Bytes (21%) des dynamischen Speichers, 1599 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Beim Hochladen des Sketches ist ein Fehler aufgetreten



Sketch
/*
* The MySensors Arduino library handles the wireless radio link and protocol
* between your home built sensors/actuators and HA controller of choice.
* The sensors forms a self healing radio network with optional repeaters. Each
* repeater and gateway builds a routing tables in EEPROM which keeps track of the
* network topology allowing messages to be routed to nodes.
*
* Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
* Copyright (C) 2013-2018 Sensnology AB
* Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
*
* Documentation: http://www.mysensors.org
* Support Forum: http://forum.mysensors.org
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* version 2 as published by the Free Software Foundation.
*
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
*
* DESCRIPTION
* Example sketch showing how to control physical relays.
* This example will remember relay state after power failure.
* http://www.mysensors.org/build/relay
*/

// Enable debug prints to serial monitor
#define MY_DEBUG

// Enable and select radio type attached
#define MY_RADIO_RF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

// Enable repeater functionality for this node
#define MY_REPEATER_FEATURE

#include <MySensors.h>

#define RELAY_PIN 4  // Arduino Digital I/O pin number for first relay (second on pin+1 etc)
#define NUMBER_OF_RELAYS 1 // Total number of attached relays
#define RELAY_ON 1  // GPIO value to write to turn on attached relay
#define RELAY_OFF 0 // GPIO value to write to turn off attached relay


void before()
{
for (int sensor=1, pin=RELAY_PIN; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Then set relay pins in output mode
pinMode(pin, OUTPUT);
// Set relay to last known state (using eeprom storage)
digitalWrite(pin, loadState(sensor)?RELAY_ON:RELAY_OFF);
}
}

void setup()
{

}

void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Relay", "1.0");

for (int sensor=1, pin=RELAY_PIN; sensor<=NUMBER_OF_RELAYS; sensor++, pin++) {
// Register all sensors to gw (they will be created as child devices)
present(sensor, S_BINARY);
}
}


void loop()
{

}

void receive(const MyMessage &message)
{
// We only expect one type of message from controller. But we better check anyway.
if (message.type==V_STATUS) {
// Change relay state
digitalWrite(message.sensor-1+RELAY_PIN, message.getBool()?RELAY_ON:RELAY_OFF);
// Store state in eeprom
saveState(message.sensor, message.getBool());
// Write some debug info
Serial.print("Incoming change for sensor:");
Serial.print(message.sensor);
Serial.print(", New status: ");
Serial.println(message.getBool());
}
}



Als Programmer ist standardmäßig noch AVRISP mll ausgewählt

Klicke ich einfach nur auf hochladen erhalte ich folgendes:


Der Sketch verwendet 13676 Bytes (44%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 449 Bytes (21%) des dynamischen Speichers, 1599 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00