WLAN Schaltsteckdose

Allgemeines

"OMG, warum baut der eine WLAN-Steckdosenleiste, wenn's sowas doch fertig zu kaufen gibt?" [1]

Die meisten, bzw. alle, die ich bis jetzt gefunden habe erfuellen nicht alle Kriterien und die Betonung liegt auf Steckdosenleiste.

Auswahlbedingungen:

• Rueckmeldefunktion: schaltbar von mehreren "Stellen" mit gegenseitiger Anzeige des aktuellen Schaltzustandes.
• FHEM-Intergration, oder "offene"-Schnittstelle. Eine Smartphone-App-Steuerung ist ja selten daemlich.
• Cloudfree Wie viele Apps/Clouds soll ich noch installieren.
• Skalierbar 2,3,4,... Steckdosen.
• evtl. Dimmerfunktion
• Preis, selbst wenn man SONOFF (z.B. SONOFF POW R2 1 Kanal Schaltaktor WLAN, mit Messfunktion) nimmt.

Smartphone-App-Steuerung

Schalten muss schnell und einfach sein!

Was nutzt es mir wenn ich fuer jeden Smartplug-Hersteller eine andere App benoetige.

Selbst wenn ein Schlauer auf die Idee kommt, alles in einer App zu integrieren, muss ich idR die App oeffnen und navigieren. Da nutzen auch keine SprachassistentINNEN, solange ER nicht Jarvis heiszt und mit WENIGEN Angaben weiss, was ER zu tun hat.

Vorhaben 1

Einzeln schaltbare Steckdosenleisten sind schon unter 10 Euro zu haben. Ein Umbau lohnt eigentlich nicht. Da die Einbausteckdose 713 von Bals schon fuer 2 Euro/Stueck zu haben ist. Na gut, man muss den Gehaeusepreis dazurechnen. Als Gehaeuse kann ein Stueck Kabelkanal dienen.

Vorhaben 2

Vorhaben 3

NodeMCU

Allen Vorhaben liegen aehnliche Vorderungen zugrunde.

• WLAN-Anbindung
• MQTT-Steuerung
• Toggletaster
• Signalisierung Schaltzustand
• 1-polige-/2-polige-Trennung

...

Software

Ausgehend von dem Testprgramm aus dem Artikel NodeMCU beginnt jetzt die Bereinigung, Optimierung und Anpassung des Codes. Der Uebersichtlichkeit geschuldet packe ich die Kommentare in den Quellcode.

Forderung an die Software:

• Parameter zur Anpassung
• Interrupts

Firmeware NodeMCU (ESP8266) Schaltsteckdose

//funktioniert 20210821 mit NodeMCU ueber USB
//Blink fehlt noch
#include <Arduino.h>            // in den DHT examples benutzt
#include <Ticker.h>             // in den DHT examples benutzt, esp8266 library that calls functions periodically
#include <ESP8266WiFi.h>        // Include the Wi-Fi library
#include <PubSubClient.h>       // MQTT 
#include <DHT.h>                // DHT Temp/Hum DHT11 DHT22
#include <PCF8574.h>            // I2C Port-Expander 8 IN/OUT
#include <Wire.h>               // This library allows you to communicate with I2C / TWI devices 


// WLAN //
WiFiClient espClient;
const char* ssid     = "XXX";         // The SSID (name) of the Wi-Fi network you want to connect to
const char* password = "YYY";     // The password of the Wi-Fi network


// MQTT //
const char* mqtt_server = "192.168.178.x";
PubSubClient client(espClient);
unsigned long lastMsg = 0;
#define MSG_BUFFER_SIZE	(50)
char msg[MSG_BUFFER_SIZE];
long int value = 0;

// DHT //
Ticker ticker;
DHT11 sensor;  // change to DHT22 if needed!
volatile float humidity = 0;
volatile float temperature = 0;
volatile uint8_t error = 0;
volatile int8_t result = 0;
int grad = 248; // mit dem Gradzeichen gibt es schon mal Probleme

void readDHT() {  // Funktion eigentlich ueberfluessig, da nur eine (weitere) Funktion aufgerufen wird 
  sensor.read();
}

//PCF
PCF8574 PCF(0x20);   // Man beachte, dass die Slave-Adresse nur 7-Bit lang ist und nicht zwischen R/W unterscheidet.

// this callback will be called from an interrupt
// it should be short and carry the ICACHE_RAM_ATTR attribute
void IRAM_ATTR handleData(float h, float t) {
  humidity = h;
  temperature = t;
  result = 1;
}

// this callback will be called from an interrupt
// it should be short and carry the ICACHE_RAM_ATTR attribute // ICACHE_RAM_ATTR veraltet
void IRAM_ATTR handleError(uint8_t e) {
  error = e;
  result = -1;
}

void callback(char* topic, byte* payload, unsigned int length) {
  Serial.print("Message arrived [");
  Serial.print(topic);
  Serial.print("] ");
  for (unsigned int i = 0; i < length; i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();

  // Switch on the LED if an 1 was received as first character
  // Ein Moeglichkeit der Auswertung um Schaltzustaende zu aendern
  if ((char)payload[0] == '1') {
    digitalWrite(LED_BUILTIN, LOW);   // Turn the LED on (Note that LOW is the voltage level
    // but actually the LED is on; this is because
    // it is active low on the ESP-01)
  } else {
    digitalWrite(LED_BUILTIN, HIGH);  // Turn the LED off by making the voltage HIGH
  }

}

// MQTT Verbindung nicht vorhanden
void reconnect() {
  // Loop until we're reconnected
  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    // Create a random client ID
    String clientId = "ESP8266Client-";
    clientId += String(random(0xffff), HEX);  // ClientID muss in die global configs 
    // Attempt to connect
    if (client.connect(clientId.c_str())) {
      Serial.println("connected");
      // Once connected, publish an announcement...
      client.publish("outTopic", "hello world");   // outTopic muss in die global configs
      // ... and resubscribe
      client.subscribe("inTopic");
    } else {
      Serial.print("failed, rc=");
      Serial.print(client.state());
      Serial.println(" try again in 5 seconds");
      // Wait 5 seconds before retrying
      delay(5000);
    }
  }
}

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);     // Initialize the BUILTIN_LED (alte Bezeichnung) pin as an output

 // Die ganze serielle Kommunikation braucht man eigentlich nur zum  Debuggen 
  Serial.begin(115200);         // Start the Serial communication to send messages to the computer
  delay(10);
  Serial.println('\n');

  //sensor.setup(D4);
  sensor.setPin(D8);
  sensor.onData(handleData);
  sensor.onError(handleError);
  ticker.attach(30, readDHT);

  WiFi.mode(WIFI_STA);// ist scheinbar der defaultwert wird in letzter Version nicht benutzt
  WiFi.begin(ssid, password);             // Connect to the network
  Serial.print("Connecting to ");
  Serial.print(ssid); Serial.println(" ...");

  int i = 0;
  while (WiFi.status() != WL_CONNECTED) { // Wait for the Wi-Fi to connect
    delay(1000);
    Serial.print(++i); Serial.print(' ');
  }

  randomSeed(micros());

  Serial.println('\n');
  Serial.println("Connection established!");
  Serial.print("IP address:\t");
  Serial.println(WiFi.localIP());         // Send the IP address of the ESP8266 to the computer

  client.setServer(mqtt_server, 1883);
  client.setCallback(callback);

  PCF.begin();
}

void loop() {
  if (result > 0) {
    Serial.printf("Humid: %g %%\n", humidity);
    Serial.println();
    Serial.printf("Temp: %3.1f %cC\n", temperature,grad);
    Serial.println();
  } else if (result < 0) {
    Serial.printf("Error: %s\n", sensor.getError());
  }
  result = 0;
  if (!client.connected()) {
  reconnect();
  }
  client.loop();

  unsigned long now = millis();
  if (now - lastMsg > 2000) {
    lastMsg = now;
    ++value;
    snprintf (msg, MSG_BUFFER_SIZE, "hello world #%ld", value);
    Serial.print("Publish message: ");
    Serial.println(msg);
    client.publish("outTopic", msg);
    PCF.toggle(4);
  }
}

MQTT Topics

Zur Zeit zeigt sich durch Tests in FHEM noch Kraut und Rueben.

Hier mal eine kleine Zusammenstellung der Dos and Donts or Best practices

Never use a leading forward slash

A leading forward slash is permitted in MQTT. For example, /myhome/groundfloor/livingroom. However, the leading forward slash introduces an unnecessary topic level with a zero character at the front. The zero does not provide any benefit and often leads to confusion. Topic names must consist of at least one character to be valid.

/

is already a topic name.

Never use spaces in a topic

A space is the natural enemy of every programmer. When things are not going the way they should, spaces make it much harder to read and debug topics. As with leading forward slashes, just because something is allowed, doesn’t mean it should be used. UTF-8 has many different white space types, such uncommon characters should be avoided.

Keep the topic short and concise

Each topic is included in every message in which it is used. Make your topics as short and concise as possible. When it comes to small devices, every byte counts and topic length has a big impact.

Use only ASCII characters, avoid non printable characters

Because non-ASCII UTF-8 characters often display incorrectly, it is very difficult to find typos or issues related to the character set. Unless it is absolutely necessary, we recommend avoiding the use of non-ASCII characters in a topic. Embed a unique identifier or the Client Id into the topic It can be very helpful to include the unique identifier of the publishing client in the topic. The unique identifier in the topic helps you identify who sent the message. The embedded ID can be used to enforce authorization. Only a client that has the same client ID as the ID in the topic is allowed to publish to that topic. For example, a client with the client1 ID is allowed to publish to client1/status, but not permitted to publish to client2/status.

Don’t subscribe to #

Sometimes, it is necessary to subscribe to all messages that are transferred over the broker. For example, to persist all messages into a database. Do not subscribe to all messages on a broker by using an MQTT client and subscribing to a multi-level wildcard. Frequently, the subscribing client is not able to process the load of messages that results from this method (especially if you have a massive throughput). Our recommendation is to implement an extension in the MQTT broker. For example, with the plugin system of HiveMQ you can hook into the behavior of HiveMQ and add an asynchronous routine to process each incoming message and persist it to a database.

Don’t forget extensibility

Topics are a flexible concept and there is no need to preallocate them in any way. However, both the publisher and the subscriber need to be aware of the topic. It is important to think about how topics can be extended to allow for new features or products. For example, if your smart-home solution adds new sensors, it should be possible to add these to your topic tree without changing the whole topic hierarchy.

Use specific topics, not general ones

When you name topics, don’t use them in the same way as in a queue. Differentiate your topics as much as possible. For example, if you have three sensors in your living room, create topics for myhome/livingroom/temperature, myhome/livingroom/brightness and myhome/livingroom/humidity. Do not send all values over myhome/livingroom. Use of a single topic for all messages is a anti pattern. Specific naming also makes it possible for you to use other MQTT features such as retained messages. For more on retained messages, see part 8 of the Essentials series.

Diese Zusammenstellung empfand ich als sehr hilfreich.

In meinem Haus hat jeder Raum bereits eine Nummer mit vorangestelltem UG, EG und DG. Jetzt kaeme noch der Garten als neuer "Raum" dazu. Oder ich entscheide eine Stufe darueber bereits zwischen Haus und Garten. Da ich im Garten zwischen Pool Carport unterscheiden will, muss ich wohl auch noch eine Unterteilung nach Terrasse hinzufuegen. Bisher habe ich das alles in FHEM unter "Auszen" zusammengefasst. Die erste Ebene waere also Haus/Außenanlage, Außenbereich oder einfach nur Außen.

Noch etwas detaillierter geht es hier weiter.

Ein erster Versuch fuer mich sieht dann so aus (weder am Anfang noch am Ende steht ein Slash):

Haus/[UG,EG,DG]/[1-9]+/ClientID/Art
Außen/[Terrasse,Veranda,Garten,Pool,Carport,...]/ClientID/Art

Art waere dann [Schalter,Temperatur,Feuchtigkeit,Dimmer,...]

Einen Payload im JSON-Format benoetige ich erst mal nicht. Ich werde nach Moeglichkeit numerische Payloads gebrauchen. Spaetestens wenn man mehrere Schalter in einem Client vereint stellt sich die Frage ob ich z.B. fuer jeden Schalter einen Topic anlege, oder im Topic Schalter eine Zahl als Repraesentation aller Schalter uebergebe.

Zum Beispiel:

..../ClientID/Schalter1 0      
..../ClientID/Schalter2 0
..../ClientID/Schalter3 1
..../ClientID/Schalter4 0
..../ClientID/Schalter5 1

oder

..../ClientID/Schalter 00101

Da ich im zweiten Beispiel den aktuellen Zustand erst bestimmen muss um die Message zu erzeugen faellt die Wahl auf die erste Variante. Auf Unterstriche zur Bedeutungs-/Worttrennung verzichte ich.

DEBUG-Mode

Die ganzen Serial-Prints kommen in eine bedingte Kompilierung.

Links

https://cmatic.de/?accessid=2&id=16

Request for Comments

Loading comments...