Autor Thema: [Gelöst] Firmata-ähnliches MQTT?  (Gelesen 344 mal)

Offline pula

  • Sr. Member
  • ****
  • Beiträge: 556
[Gelöst] Firmata-ähnliches MQTT?
« am: 01 Februar 2018, 10:25:50 »
Hallo,

habe seit über zwei Jahren Firmata im Einsatz, hauptsächlich um eine 16Port Relais-Karte zu steuern, was aber bei einem fhem-Neustart immer abenteuerlich ist.
Kennt hier jemand eine (fertige) Alternative für UNO oder Mega über Ethernet-Shield? Oder heisst es hier wieder selber programmieren?

Cheers,
Pula
« Letzte Änderung: 01 März 2018, 23:10:57 von pula »
fhem unter debian, hm mit HM-LAN, HM-wired, arduino firmata, mysensors, fritzbox, kodi auf cubox, vdr, onkyo, squeezeplayer auf raspi, nanoCUL, wifilight über Arduino-Ethernet-Bridge, HMW-Homebrew, Heizungssteuerung über python und vncdotool, ESP/Arduinos mit MQTT

Offline pula

  • Sr. Member
  • ****
  • Beiträge: 556
Antw:Firmata-ähnliches MQTT?
« Antwort #1 am: 03 Februar 2018, 21:46:43 »
Alles muss man selber machen  ;)

Hab mal schnell einen Sketch für einen UNO mit W5100 Ethernet-Shield für MQTT gestrickt und lade ihn hier hoch, vielleicht kann ihn ja mal jemand brauchen. Ist allerdings im Gegensatz zu Firmata momentan NUR schreibend (für Relais).
Ist nicht besonders elegant, funktioniert bei mir aber soweit. (Eigenartigerweise kommt ein heftiger Compiler-Fehler, wenn ich direkt nach dem Öffnen der Arduino IDE 1.6.5 für UNO kompiliere. Ich muss zuerst das board auf "NodeMCU 1.0 (ESP-12E Module)" umstellen, einmal kompilieren und dann wieder auf UNO umstellen, dann läuft der compile durch). Mit einer neueren Version der IDE habe ich hier auch keine guten Erfahrungen gemacht und weiß auch nicht, ob der Sketch ordentlich tut.

Was kann er?
Bis zu 16 Relais (GPIO 2 - 17) ansteuern. Er merkt sich den Status im EEPROM, sodaß nach einem Reset oder Stromausfall alles erhalten bleibt. Außerdem gibt es ein topic (watchdog), bei dem das Ding den Status aller Relais published.
Am Anfang des Sketches ist alles zu konfigurieren, sollte halbwegs selbsterklärend sein:
// CHANGEME
byte mac[] = { 0xD0, 0xAB, 0x1E, 0xEF, 0xFE, 0xED };
#define clientID "uno1"
const char* mqtt_server = "192.168.1.11";
const char* mqtt_user = "otto";
const char* mqtt_pass = "password";
char* outTopicState = "/uno1/output/rel_";
char* inTopicSet = "/uno1/input/switch_";
char* inTopicSetAll = "/uno1/input/+";  //necessary because pubSubClient has difficulties to subscribe more than 4 (?) topics at once...
char* inTopicWatchdog = "/uno1/input/watchdog"; //publishes state of all relays (no matter which payload is received)
char* inTopicReset = "/uno1/input/reset"; //resets the arduino no matter what payload is received
const byte minGPIO = 2;
const byte maxGPIO = 17;
// CHANGEME END

Ein zugehöriges device habe ich folgend definiert:
define uno1_02_mqtt MQTT_DEVICE
attr uno1_02_mqtt IODev mqtt
attr uno1_02_mqtt subscribeReading_status /uno1/output/rel_02
attr uno1_02_mqtt publishSet on off /uno1/input/switch_02
attr uno1_02_mqtt publishSet_reset /uno1/input/reset
attr uno1_02_mqtt publishSet_watchdog /uno1/input/watchdog
attr uno1_02_mqtt devStateIcon status:on:FS20.on status:*:FS20.off
attr uno1_02_mqtt eventMap 1:on 0:off
attr uno1_02_mqtt room MQTT
attr uno1_02_mqtt stateFormat status
(Wobei man das reset- und watchdog-topic nur in einem device definieren muss, falls man es überhaupt braucht.)
Allerdings ist scheinbar die Reihenfolge, in der man die Attribute definiert wichtig (zuerst die subscriptions und publishSets).

Den Status kann man wahlweise per 0,1,on, off setzen oder auch per toggle (schaltet den Status um).

Vielleicht kann das ja mal irgendwer brauchen. Das Ganze sollte sich auch sehr einfach auf einen ESP portieren lassen, indem man den Ethernet-Teil durch die entsprechenden WIFI-Aufrufe ersetzt, aber ich persönlich bin ein Kabel-Freund, wenn es um die Hausautomatisierung geht...

Cheers,

Pula
« Letzte Änderung: 26 Februar 2018, 22:33:13 von pula »
fhem unter debian, hm mit HM-LAN, HM-wired, arduino firmata, mysensors, fritzbox, kodi auf cubox, vdr, onkyo, squeezeplayer auf raspi, nanoCUL, wifilight über Arduino-Ethernet-Bridge, HMW-Homebrew, Heizungssteuerung über python und vncdotool, ESP/Arduinos mit MQTT

Offline pula

  • Sr. Member
  • ****
  • Beiträge: 556
Antw:Firmata-ähnliches MQTT?
« Antwort #2 am: 14 Februar 2018, 00:46:26 »
Falls jemand Interesse hat:
Hab jetzt noch einen Sketch für einen Mega mit W5100 für MQTT gebaut:
24 Relais und 15 Eingänge (entprellt)....

Cheers,

Pula
fhem unter debian, hm mit HM-LAN, HM-wired, arduino firmata, mysensors, fritzbox, kodi auf cubox, vdr, onkyo, squeezeplayer auf raspi, nanoCUL, wifilight über Arduino-Ethernet-Bridge, HMW-Homebrew, Heizungssteuerung über python und vncdotool, ESP/Arduinos mit MQTT

Offline pula

  • Sr. Member
  • ****
  • Beiträge: 556
Antw:Firmata-ähnliches MQTT?
« Antwort #3 am: 01 März 2018, 23:10:38 »
Lade das hier mal hoch.
Ein Sketch für den Arduino Mega und W5100-Ethernet. (der UNO kann das auch, aber aufgrund der schwächeren Hardware wesentlich weniger - habe den Sketch auf einem UNO mit 4 Tastern und 2 Relais erfolgreich im Einsatz)
15 entprellte Taster-Eingänge.
27 Relais-Ausgänge mit ActiveLow-Unterstützung (es kann also per fhem/mqtt umgestellt werden, ob high/low ein/aus ist oder umgekehrt).
Stati werden im EEPROM gespeichert.
Funktioniert bei mir seit ca. zwei Wochen stabil.
Bitte die Anmerkungen im Sketch bezüglich RC.Netz beachten.
Die Werte innerhalb der CHANGEME-Kommentare müssen nach Gegebenheit angepasst werden.

Vielleicht kanns mal jemand brauchen....
Cheers,
Pula
fhem unter debian, hm mit HM-LAN, HM-wired, arduino firmata, mysensors, fritzbox, kodi auf cubox, vdr, onkyo, squeezeplayer auf raspi, nanoCUL, wifilight über Arduino-Ethernet-Bridge, HMW-Homebrew, Heizungssteuerung über python und vncdotool, ESP/Arduinos mit MQTT