ESP8266 über WLAN an KNX

[tuxedo]

@OleDeluxe
Primär muss KONNEKTING erstmal eine Stabile Version 1.0.0 erreichen. Aktuell steht die beta5 auf dem Plan, die dann, so die Idee, nach einer Testphase in Version 1.0.0 über geht.

Danach werden wir schauen dass wir weitere Features anbinden, so auch (recht weit vorne auf der ToDo), die KNX-IP Anbindung. Weil die macht gerade für Nachrüstungen im DIY Bereich durch die WLAN-Konnektivität des ESP (und Konsorten) am meisten Sinn. KNX quasi überall auch da, wo man keine Busleitung liegen hat, bzw. vergessen hat beim Bau zu berücksichtigen.

[ragepw]

halloween :
http Kommandos sind möglich siehe hier:

[halloween]

Das hab ich gelesen, aber ich hab das so verstanden, dass ich damit http-commands an den Sonoff senden kann.

Ich meinte die umgekehrte Richtung, wenn also z.B. der Sonoff POW mir den Stromverbrauch ausgibt. In Openhab kann ich mittels der Rest API meine Items durch ganz normale http-get Befehle verändern, wie es auch jeder Browser versenden kann.

------------------------

Und unabhängig von der obigen Frage:

Wie sicher ist eigentlich so ein ESP8266?

Angenommen ich baue mir im Briefkasten einen Reedkontakt ein mit einem batteriebetriebenem ESP8266. Wenn jemand den klaut, kann er dann meine WLAN Zugangsdaten (WPA2) auslesen und sich - auch ohne Zugang zu einem Buskabel - in mein KNX einhacken? Ganz einfach z.B. aus dem vorm Haus geparktem Auto?

Auch wenn er dann vielleicht nicht das Motorschloss bedienen kann, wenn das über KNX nicht erreichbar ist, käme er ja problemlos auf die VISU und könnte darüber die Tür öffnen. Ich nutze Openhab und im internen Netz läuft die Weboberfläche ohne Passwortabfrage.

[wintermute]

Wie sicher ist eigentlich so ein ESP8266?

Die Frage zielt eigentlich nicht auf den ESP "an sich"...
Wenn Dir ein WLAN-Teilnehmer geklaut wird, dann kann sich jemand (erstmal auch ohne jeglichen Aufwand) damit mit Deinem WLAN verbinden. Um das zu verhindern laesst man nur bestimmte MAC-Adressen zu und entfernt die MACs der "verschwundenen" Geraete aus den betreffenden Listen. Also im Prinzip genau so, wie man mit einer "verschwundenen" Kreditkarte umgehen taete.
Das betrifft jetzt erstmal dein WLAN, befindet sich jemand (wie und warum auch immer) unauthorisiertes in Deinem WLAN hast Du generell schonmal ernste Probleme, wenn es dabei jetzt konkret um den Zugriff auf KNX geht: der Zugriff laesst sich auf IP-Firewall-Ebene nach IP-Adressen und auf Linienkoppler-(also KNX-Router)-Ebene per Filtertabellen auf KNX-Protokollebene beschraenken.
Zugriff auf Deine Visu aus dem WLAN heraus sollte sich ebenfalls per Firewall einschraenken lassen (je nach Modell auf IP-Adressen und/oder MAC-Adressen).

Konkret zum ESP: man kann den Code da wieder rauslesen, allerdings nicht den menschenlesbaren Source-Code sondern nur den Maschinencode. Den koennte man aber disassemblieren und kaeme so an die Daten. Oder aber die Daten sind im Klartext irgendwo im EEPROM gespeichert, dann kann man die "einfach so" auslesen.
Man kann das Auslesen prinzipiell unterbinden, ich weiss aber nicht wie (und ob ueberhaupt) sowas im "Arduino-Maker-Umfeld" ueberhaupt moeglich ist.

Am besten einfach nicht den Briefkasten klauen lassen

[tuxedo]

Die MAC-Adresse ist kein ernst zu nehmender Schutzmechanismus. MAC-Adressen lassen sich ohne Schwierigkeiten manipulieren. Das schafft jedes Script-kiddie mit Youtube in 5min.

Wenn dir jemand dein Auto klaut, in dem der Hausschlüssel liegt, dann hast du da genauso verloren, wie wenn dir jemand deinen WLAN-fähigen Briefkasten klaut.

Fazit: Nach dem Einbruch mit dem Hausschlüssel/Passwort die Schlösser/Verschlüsselung/Passwörter tauschen und generell schauen dass Diebstahl unmöglich/unrentabel wird.

Der ESP ist in der Hinsicht nicht unsicherer als alle anderen durchschnittlichen Konsumer-WLAN-Endgeräte.

[wintermute]

Die MAC-Adresse ist kein ernst zu nehmender Schutzmechanismus

Stimmt, aber es ist eine zusaetzliche Huerde.
Totale Sicherheit und Vernetzung (egal welcher Art) schliessen sich prinzipbedingt aus, man kann nur versuchen es so gut wie moeglich zu machen und dazu gehoert eben auch eine Positivliste fuer erlaubte MACs.
Das ist aber nur meine Meinung

[Monti]

Die Tasmota Firmware kann nur über MQTT mit der Aussenwelt komunizieren, oder?

Tasmota kann sich auch als HUE-Bridge, WEMO oder Domoticz ausgeben. Der Sourcecode für das jeweilige Protokoll ist ja in einzelne Dateien ausgelagert. Man müsste die Anpassungen für KNX in dieser Art durchziehen.

[Harry49]

Es wäre toll, wenn jemand ein funktionierendes Sketch für den ESP8266 als Beispiel posten könnte (natürlich ohne sein WLAN-Passwort).
Möglichst einfach (z.B. nur zum Schalten = Weihnachtsbeleuchtung).
Das Beispiel unter "ESP-KNX-IP" in GitHub führt bei mir beim Kompilieren immer zur Fehlermeldung "'my_callback' was not declared in this scope".
Danke!

[OleDeluxe]

Hi,
versuch es mal mit folgendem Sketch, der müsste so schon fast auf den Sonoff Basic passen.
Er benötigt 2 GA:
- Schalten
- Rückmelden

Gleichzeitig kann mit einem Button, der am ESP angeschlossen ist vor Ort getoggelt werden.

#include <esp-knx-ip.h>

// WiFi config
const char* ssid = "DEINE_SSID";        //ANPASSEN !
const char* pass = "DEIN_PASSWORT";     //ANPASSEN !

unsigned long next_data_change = 0;

int val = 0;
int Button1_Pin = 0;    //Ein Button um manuell am ESP den Ausgang umzuschalten
int Relais1_Pin = 12;   //Hier ist der Ausgang, der geschaltet wird, bspw. ein Relais
int LED_PIN = 13;
int buttonState = 0;
int Relais1State = 0;
int lastButtonState = 1;
int Button1_Flag = 0;

config_id_t Relais1_Status_GA;  //Die Rückmelde GA, auf die der ESP sendet
config_id_t hostname_id;

//Der folgende Callback schaltet den Ausgang wenn auf die GA gesendet wird
void Relais1_callback(knx_command_type_t ct, address_t const &received_on, uint8_t data_len, uint8_t *data)
{
    switch (ct)
    {
      case KNX_CT_WRITE:
        Serial.print("State of output ==> ");
        Serial.println(*data);
        digitalWrite(Relais1_Pin, *data);                             //Hier wird das Relais auf den gesendeten Status gesetzt
        knx.write1Bit(knx.config_get_ga(Relais1_Status_GA), *data);   //Hier meldet der ESP auf der RM-Ga den Status des Relais zurück
        break;
    }
}

//Der folgende Callback gibt den State des Relais bei Anfrage zurück auf die RM-GA
void Relais1_Status_callback(knx_command_type_t ct, address_t const &received_on, uint8_t data_len, uint8_t *data)
{
    switch (ct)
    {
      case KNX_CT_READ:
        Serial.print("Anfrage nach State des Relais");
        Relais1State = digitalRead(Relais1_Pin);
        knx.answer1Bit(knx.config_get_ga(Relais1_Status_GA), Relais1State); //Hier meldet der ESP auf der RM-Ga den Status des Relais zurück
        break;
    }
}

void setup() {
    pinMode(LED_PIN, OUTPUT);
    pinMode(Relais1_Pin, OUTPUT);
    pinMode(Button1_Pin, INPUT_PULLUP);
    Serial.begin(9600);

    // Register the callbacks
    knx.register_callback("Relais 1 --> SCHALTEN", Relais1_callback);
    knx.register_callback("Relais 1 --> ABFRAGEN", Relais1_Status_callback);

    // Register the group addresses
    Relais1_Status_GA = knx.config_register_ga("Relais 1 --> RM");

    // And the config options
    hostname_id = knx.config_register_string("Hostname", 20, String("env"));

    // Load previous values from EEPROM
    knx.load();

    // Init WiFi
    WiFi.hostname(knx.config_get_string(hostname_id));
    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, pass);

    Serial.println("");
    Serial.print("[Connecting]");
    Serial.print(ssid);

    digitalWrite(LED_PIN, LOW);
    while (WiFi.status() != WL_CONNECTED) {
        digitalWrite(LED_PIN, HIGH);
        delay(500);
        Serial.print(".");
        digitalWrite(LED_PIN, LOW);
    }
    digitalWrite(LED_PIN, HIGH);


    // Start knx
    knx.start();

    Serial.println();
    Serial.println("Connected to wifi");
    Serial.println(WiFi.localIP());
    Serial.println(" ");
}

void loop() {
    // Process knx events, e.g. webserver
    knx.loop();

    //Umschalten des Relais mit OnboardButton bei Positiver Flanke
    buttonState = digitalRead(Button1_Pin);
    Relais1State = digitalRead(Relais1_Pin);
    if (buttonState != lastButtonState) {
      if (buttonState == LOW) {
        if (Relais1State == 1) {
          digitalWrite(Relais1_Pin, LOW);
          knx.write1Bit(knx.config_get_ga(Relais1_Status_GA), 0);   //Senden des Status auf die RM-GA
          }
          else if (Relais1State == 0){
          digitalWrite(Relais1_Pin, HIGH);
          knx.write1Bit(knx.config_get_ga(Relais1_Status_GA), 1);   //Senden des Status auf die RM-GA
          }
      } 
    }
    lastButtonState = buttonState;
  delay(50);
}

kompilieren tut er, kann es aber grad nicht auf nem ESP testen.

MFG Sven

[Harry49]

Danke Sven!
Dein Sketch funktioniert auf Anhieb und hat mir sehr viel Arbeit erspart. Habe es zur Probe auf einen ESP-01 geladen, wo es sofort lief. Endlich eine Lösung für die Stellen, an denen kein Buskabel liegt (wie die Weihnachtsbeleuchtung draußen). Von Sonoff werde ich mal ein Muster bestellen und ausprobieren. Für eine KNX-WLAN-Steckdose wird es sicher eine Verwendung geben.
Gruß
Stephan

[OleDeluxe]

Gern geschehen!

Genau dafür ist das Top. Habe mir auch mal eine Sonoff S20 bestellt als Steckdose und heute kam ein Sonoff 4ch pro. Evtl. ersetzte ich damit den Eigenbau im Schuppen.
Als Addon will ich da noch einen Watchdog laufen lassen und die Meldung über Pushover einbinden, wenn mal die Verbindung zu Edomi abbricht. Edomi selbst überwacht die ESP schon und meldet per Pushover.

MfG Sven

[halloween]

Wie darf ich mir das vorstellen mit dem Watchdog?

Sendet dein Server aktuell alle paar Sekunden einen Ping zum WLAN-Gerät?

Und zukünftig willst du dann das WLAN-Gerät alle paar Sekunden einen Ping senden lassen?

[OleDeluxe]

Hierzu nutze ich in Edomi den entsprechenden LBS Watchdog. Der ESP sendet in regelmäßigen Abständen auf eine GA, die wiederum den Watchdog Timer zurück setzt. Parallel dazu antwortet Edomi dann auf eine GA, die im ESP einen Timer zurücksetzt. Bricht mir einfach die Verbindung zu Edomi ein, so sendet der ESP via Pushover eine Meldung auf mein Handy. Sollte Der ESP abschmieren oder das Wifi verlieren, so meldet Edomi via Pushover, dass die Meldung ausblieb.
ich habe ein Intervall von 15 Minuten drin, mit eben etwas Totzeit, aber das ist mMn eher von dem abhängig was am anderen Ende läuft; bei mir ist das z.B. etwas Beleuchtung im garten, also eher unkritisch.
Gleichzeitig möchte ich mir in Status-Seite der Visu auch noch ein paar Infos wie etwa Wifi-Signal-Stärke zum ESP anzeigen lassen.

Gruß, Sven

[Sisamiwe]

Ich mische mich hier mal ein....
Ich nutze ein paar SONOFF mit shNG. Auch da habe ich ein Watchdog eingebaut. Er basiert darauf, dass der ESP via MQTT in meinem Fall regelmäßig eine Meldung absetzt. Diese Meldung setzt den Watchdog zurück bzw. lässt ihn passiv. Bleibt die Meldung aus, setzt der Watchdog einen Warnmeldung ab.

OleDeluxe
Siehst Du eine Change, in die Sketch aus Beitrag 54 auch den Anschluss von weiteren Sensoren an die GPIOs des SONOFF zu implementieren?
Wenn man bspw die Temp eines angeschlossenen 1wire TempSensors auf eine weitere GA senden könnte, wäre das super. In der Tasmota ist das auch umgesetzt.
Meinst Du, das geht?

Danke und Gruß Michael

[OleDeluxe]

Das ist ja nur nen Beispiel. Da kann man alles mit senden was man sonst auch mit nem arduino macht. Ich habe beispielsweise einen dht22 am laufen, möchte damit als nächstes eine kleine Wetterstation basteln.

Mfg Sven