Statusanzeige für die Hausautomation mit Neopixel und MQTT

Harry L. schrieb:

> Damit führst du die normale Funktionsweise von MQTT ad absurdum.
> Sowas kann man sich nur erlauben, wenn man sicher sein kann, daß alle
> MQTT-Nachrichten tatsäclich ohne JSON auskommen, und das ist in der
> realen Welt nicht der Fall.

ich glaube, wir reden über verschiedene Dinge.

Wenn ich Nachrichten im JSON-Format empfange oder sende, dann kann ich 
auf die entsprechenden Bibiotheken nicht verzichten.
Aber das JSON-Format wird im konkreten Fall nicht zur Datenübertragung 
benutzt.

JSON wird benutzt, um die RGB-Werte für blinkende LED's in JSON-Objekten 
zu speichern.
Ein Array mit uint8_t kann diesen Zweck mit deutlich weniger Overhead 
erfüllen.

Aber selbstverständlich - viele Wege führen nach Rom.

> Wieso man unbedingt Resourcen sparen muß, die anderweitig nicht benötigt
> werden, erschließt sich mir sowieso nicht.

Zum Thema "ressourcenschonen".
Wenn man mit ATtinys und ATmegas arbeitet, dann ist man schon gezwungen, 
möglichst kompakten Code zu schreiben.

In den Beispielen zu ArduinoJson finde ich folgenden Hinweis:

// Use String objects sparingly, because ArduinoJson duplicates them in 
the
// JsonBuffer. Prefer plain old char[], as they are more efficient in 
term of
// code size, speed, and memory usage.

Auf dem ESP8266 kann man entspannter vorgehen, da kann man sich dann 
schon mal ein "sprintf()" erlauben.

Übrigens habe ich auf die Verwendung von C++String / C-Strings komplett 
verzichten können (Ausnahme zum Debugggen), indem ich die Payload direkt 
als uint8_t ablege.

Eine sprachliche Korrektur zu meinem ersten Beitrag:
Wenn ich von "Hexadezimaler Payload" schreibe, dann ist eine Payload im 
binären / Byte-Format gemeint (bytearray[] in Python) .

mfg

Michael S.

Ich sehe auch einen grossen Vorteil darin das man Menschenlesbare 
Nachriten per MQTT verschickt. Es gibt viele Clients die sich an den 
Broker anhängen können, selbst auf dem Smartphone kann ich die Meldungen 
mitlesen. Da machen kryptische Hexcodes keinen Spass. Auch zur 
Weiterverarbeitung in NodeRed z.B. ist das mit JSON Objekten viel 
angenehmer.
Das man sich den Anachronismus mit Tinys für solche Aufgaben noch 
antut... In gleicher Größe und für nahezu gleiches Geld bekomme ich 32 
Bitter mit ausreichend Flash und RAM um auch da schon mit lesbaren Daten 
arbeiten zu können.
Wie heisst der blöde Spruch nochmal? Für nicht benutzten Flash gibts 
kein Geld zurück?

Harry L. schrieb:
> MQTT auf einem 8bit-AVR ist ohnehin eine Illusion.

Es ist immer noch ein Unterschied, ob es sich um einen Client oder 
Server handelt.

Harry L. schrieb:

> MQTT auf einem 8bit-AVR ist ohnehin eine Illusion.

Eine Menge Bla-Bla gemischt mit heißer Luft, die du in diesem Thread 
produzierst. Wäre es nicht besser du nimmst dein Eimerchen und dein 
Schauffelchen und gehst spielen?

Das Prinzip und die Idee hinter MQTT wirst du verstehen, wenn du 
erwachsen bist.

Zur allgemeinen Beruhigung der Gemüter:

Wenn man einige Zeit mit den ATtinys und ATmegas gearbeitet hat, dann 
geht einem schlankes Programmieren (zumindest der Versuch dazu) in 
Fleisch und Blut über.

Selbstverständlich läuft der MQTT-Client auf einem größeren Controller, 
nämlich dem ESP8266.


Michael S.

Ein kleiner Nachtrag:

Damit der MQTT-Client angeschlossenen Neopixels auch ohne den Umweg über 
den MQTT-Server direkt ansteuern kann, ist eine zusätzliche 
Schnittstelle in der "neopixel.ino" eingefügt:

void set_mypixel(uint8_t* pixel);

ein Array mit 6 Byte wird zur Übergabe der Parameter benötigt:
uint8_t pixel[] = {0,0,0,0,0,0};

die Bedeutung der Bytes:
pixel[0] = Start-LED
pixel[1] = rot
pixel[2] = grün
pixel[3] = blau
pixel[4] = End-LED
pixel[5] = Blinkmode [0...4]

Die Farbwerte einzelner Neopixel können natürlich auch mit einer Methode 
des neopixel-Objektes geändert werden:

pixels.setPixelColor(pixelnr, pixels.Color(rot, grün, blau));

Allerdings kann man auf diesem Wege keine Reihe von LED's setzen und 
auch den Blinkmodus nicht nutzen.

Viel Spaß beim Blinken,

Michael S.