OpenMQTTGateway -> MQTT und RollingCode .... mal wieder

Beta-User · 30 September 2019, 15:32:55

Das Binary kann ich frühestens heute abend testen, Danke schon mal (mal schauen, auf welche Adresse das geht, der ESP32 ist da etwas anders als die meisten MCU's die mir bisher über den Weg gelaufen sind...).

Für ZigBee braucht man ein spezielles GW, ich kenne zigbee2mqtt und deCONZ, gibt aber noch einige Varianten mehr. Hat beides Vor- und Nachteile, im Moment sehe ich deCONZ vorne, an zigbee2mqtt hat mich v.a. gestört, dass das auf einer Java-Basis läuft und daher einen eigenen Update-Mechanismus braucht (und gleich mit 2 moderaten Vulnerabilities kam), sonst ist das auch super.
Auf der OpenMQTTGateway-Seite gibt es diesen featurerequest: https://github.com/1technophile/OpenMQTTGateway/issues/205. Das wäre super, wenn das laufen würde, also der Java-Teil direkt auf dem Microcontroller "abgefrühstückt" werden könnte, das ganze dann via MQTT eingebunden würde (optimalerweise via USB...!) und dann auch noch ein etwas aktuellerer ZigBee-Chipsatz zum Einsatz käme als der CC253x. Vermutlich würde ich mich dann auch wieder von deCONZ verabschieden (ich bevorzuge opensource-Projekte, auch wenn's manchmal etwas "steiniger" ist), und evtl. sogar ein IO-Modul schreiben, das an USB liest und das an MQTT2_DEVICE weitergibt

.

Beta-User · 01 Oktober 2019, 14:45:16

So, Zwischenstand:

Das Binary ließ sich problemlos flashen, aber bisher hat es scheinbar keine BT-Devices erkannt. Interessant, dass das so anders ist, aber evtl. darauf zurückzuführen, dass kein Verkehr im Haus war und insbesondere die Apfel-Nutzerin schon weg (die Apple-Geräte verwenden wohl zufällig wechselnde BT-Adressen). Habe mal zwei BT-Tags bestellt, wird aber dauern, bis die aus dem fernen Osten da sind...
(Habe in der platform.io-File gesehen, dass es auch eine Option für "all" (@ESP32) zu geben scheint (und auch bmp180 einkompiliert ist; da hätte ich noch welche rumliegen). Evtl. haben die Entwickler dort das erkannt, dass es besser ist, die Pins für i2c usw. zu trennen?

Die verbesserte regex für den bme usw. ist auch seit eben im svn.

Gruß,

Beta-User

Dattel01 · 01 Oktober 2019, 15:04:48

Zitat von: Beta-User am 01 Oktober 2019, 14:45:16
Das Binary ließ sich problemlos flashen, aber bisher hat es scheinbar keine BT-Devices erkannt.

Liegt dann sicher an der fehlenden IC-Pin Konfiguration. Vielleicht findest du ja auf die Schnelle was im Code, sonst schaue ich heute Abend nochmal.

Zitat von: Beta-User am 01 Oktober 2019, 14:45:16
(Habe in der platform.io-File gesehen, dass es auch eine Option für "all" (@ESP32) zu geben scheint (und auch bmp180 einkompiliert ist; da hätte ich noch welche rumliegen). Evtl. haben die Entwickler dort das erkannt, dass es besser ist, die Pins für i2c usw. zu trennen?

Ja die Option gibt es, das ist aber immer Overkill. Wenn man schon selber kompiliert, dann kann man auch die nicht benötigten Module weglassen - gerade, wenn man mit dem ESP-01 oder dem NODEMCU die ich betreibe speichertechnisch etwas beschränkter ist.

Zitat von: Beta-User am 01 Oktober 2019, 14:45:16
Die verbesserte regex für den bme usw. ist auch seit eben im svn.

Super... werd ich auch heute Abend mal testen... Ich habe gestern schon alle alten Zöpfe abgeschnitten und laufe jetzt sauber über dein Templates, hab für die BME-LOGs noch ein paar RegEx hinzugefügt, damit da auch nur HUM/HPA/C drin landen und mein SVG's sind auch alle wieder am Start...

Das ist eine super runde und saubere Sache über die Tempaltes. Noch mal ein dickes Danke dafür.

Du darfst übrigens gerne deine Änderungswünsche bei OpenMQTTGateway einkippen

https://community.openmqttgateway.com/t/feature-suggest-customizeable-pins-e-g-for-bme280/652/2
Scheint, als wenn sich 1technophile für sinnvolle Kompatiblilätserweiterung recht offen ist...

Beta-User · 03 Oktober 2019, 12:19:22

Kurzer Zwischenstand:
Es werden doch BT-Signale empfangen, und auch RF war empfangsseitig kein Problem. Allerdings bekomme ich nichts gesendet, ist aber vermutlich ein Hardwareproblem (evtl. reicht die Power nicht, das Board hat nur einen Vin-Pin für 5V, da liegen aber nur ca. 4.6 V an, das scheint also aus dem Power-Regulator rückwärts zu kommen...).

Was nicht klappt, ist der IR-Teil, (erst mal Empfang) und da habe ich im Moment auch keine Idee, was da ggf. das Problem ist (angeschlossen ist ein CHQ 1838, damit habe ich u.A. meine MySensors-Node ausgestattet, sollte also mit der IRlib gehen, angeschlossen an D26, wie unter https://docs.google.com/spreadsheets/d/1_5fQjAixzRtepkykmL-3uN3G5bLfQ0zMajM9OBZ1bx0/edit#gid=1617051124 beschrieben).

Kommt Zeit kommt Rat...

Dattel01 · 03 Oktober 2019, 15:16:02

Vielleicht hab ich da die Lösung aus dem Code:
Nutz doch mal die 27...
Aber:

Für IR:

Code Auswählen


  #define IR_RECEIVER_PIN 27
  #define IR_EMITTER_PIN 14

FÜR RF:

Code Auswählen


  #define RF_RECEIVER_PIN 27 // D27 on DOIT ESP32
  #define RF_EMITTER_PIN 12 // D12 on DOIT ESP32

Nach meiner Auffassung hast du einfach einen Pin-Konflikt, da der Pin27 in der Basiskonfiguration sowohl für IR als auch RF genutzt wird.
Wenn du mir sagst, bei Modul du welchen Alternativpin nutzen möchtest, dann kann ich dir das nochmal kompilieren.

Beta-User · 04 Oktober 2019, 09:46:14

OK, dann haben die Jungs da das Problem auch erkannt... Die Doku paßt zur Devel-Version, da scheint für den ESP32 auch D26 als IR-Receiver-Pin definiert zu sein.

Vielleicht magst du schlicht die Devel-Version mit "all" mal hier reinwerfen, dann würde ich auch einen BMP180 mal anstöpseln? (Mein nickname ist nicht von ungefähr "Beta-User"...). Ansonsten würde mir die auf D26 aktualisierte Fassung auch schon mal weiterhelfen (Atom 1.4.0 @Kubuntu 18.4 ist kein großer Spaß, das erkennt z.B. nicht, dass Python 2.7 installiert ist und bricht daher den Start ab...)

Dattel01 · 04 Oktober 2019, 16:29:56

Anbei..
Da sind jetzt alle Module für den ESP32 reinkompiliert.

PINOUTS
RF_RECEIVER_PIN 26
RF_EMITTER_PIN 12

IR_RECEIVER_PIN 27
IR_EMITTER_PIN 14

Für den BM musst du mal schauen, ob die StandardConfig so passt.. Für den ESP01 musste ich die Pins ändern.
Ansonsten sag Bescheid - eben neu kompilieren ist kein Ding.

Ansonsten schlag ich mich gerade mit einem CC1101-Receiver rum. Der läuft hier auf einem Board mit SignalESP-Firmware, da ich irgendwie nur damit in der Lage bin 2 alte LIDL Temperatursensoren in FHEM einzubinden. Für den CC1101 gibt's seit kurzem einen separaten FORK mit einer Testimplementierung mit Hilfe einer RCSwitch Anpassung von LSATAN für OpenMqttGateway. Wenn ich da die PILight Komponente von OpenMQTT drauf los lasse, kommt im FHEM z.B sowas an:

Code Auswählen

{"message":{"binary":"110011011010101100010000","id":786602,"unit":0,"state":"off"},"protocol":"quigg_gt9000","length":"786602","repeats":2,"status":2}

Ich finde aber die jetzige Variante besser und vor allem zuverlässiger. Ich erinnere mich, dass ich damals auch mit PILight experimentiert habe, das Schalten aber nicht zuverlässig funktioniert hat.

Leider bekomme ich es absolut nicht hin, auf OpenMQTT oder irgendeinem eigenen Test-INO diesen ollen Sensor zum Empfangen der Wetterdaten von meinen LIDL-Sendern zu bewegen. Vielleicht wird's dann doch mal Zeit, die Teile auszutauschen...

Beta-User · 04 Oktober 2019, 16:55:58

Kannst du die pinouts bitte grade tauschen (ich hab' nach der devel-Version bzw. dem Sheet angefangen zu löten, und da liegt RF auf 27 und IR auf 26...

). Will nicht unbedingt den Lötkolben rausholen, um das weg von künftigen Defaults zu legen

.

Und auch was die i2c-Schnittstelle angeht, würde ich mal drauf tippen, dass die auf den defaults liegt (21+22), siehe https://randomnerdtutorials.com/esp32-i2c-communication-arduino-ide/. Bitte daher auch dort schlicht nichts definieren.

Was den ollen Lidl-Sensor angeht: Versuch's mit einem Signalduino/SignalESP in einer halbwegs aktuellen Fassung. Damit geht fast alles, was 433MHz ist...

Dattel01 · 04 Oktober 2019, 17:22:49

Anbei die gewünschte Version

Zitat von: Beta-User am 04 Oktober 2019, 16:55:58
Was den ollen Lidl-Sensor angeht: Versuch's mit einem Signalduino/SignalESP in einer halbwegs aktuellen Fassung. Damit geht fast alles, was 433MHz ist...

Eben nur bedingt... Ich bin auf der letzten Fassung mit CC1101 Implementierung und die Lidl-Wettersensoren gehen damit, aber meine Rolling-Code Bedienung werden damit dann als InterTechno Device gelistet... Jeder Tastendruck erzeugt gefühlt ein neues Device in FHEM

... Aber von dort dann dieses Device zu schalten geht nicht. Deswegen bin ich ja damit auf OpenMQTTGateway, weil ich nur so ein brauchbares, komfortables Ergebnis für meine Fernbedienung bekomme.. Die IT Devices im FHEM, die der ESP anlegt, lasse ich halt links liegen. Ich hatte nur gehofft, die Eierlegene-Woll-Milch-Sau zu betreiben und mit einem OpenMQTTGateway praktisch alles abzufackeln und mir ein staubiges SignalESP-Device zu sparen.

Beta-User · 04 Oktober 2019, 17:39:58

Na ja, eierlegende Wollmilchsau ist halt nicht so einfach...

Die bin habe ich geflasht, der ESP scheint auch im WLAN angemeldet zu sein, aber MQTT-mäßig tut sich gar nichts. Muß wohl den ESP resetten, oder?

Dattel01 · 04 Oktober 2019, 18:34:46

oh sorry..

Ist wieder meine MQTT-Config drin gewesen?
Nochmal ein neues Binary .

Beta-User · 05 Oktober 2019, 08:08:05

Thx. Irgendwas scheint mit der dev-Version nicht in Ordnung zu sein. Erst dachte ich, das hätte evtl. was mit dem BME280 zu tun, aber nachdem ich jetzt Atom+platformio am laufen habe (

), habe ich das mal rauscompiled => keine Änderung, der ESP geht gleich wieder offline...

Mal schauen, wann ich da weitermache, jetzt ist erst mal was anderes dran.

(PS: die binarys kannst du gerne wieder löschen, die belasten ab jetzt nur noch unnötig die Serverinfrastruktur des e.V....)

Dattel01 · 05 Oktober 2019, 15:38:13

Ein Grund mehr, immer nur die Module mit einzukompilieren, die man auch wirklich benötigt.. Reduziert drastisch das Fehlerrisiko..

Beta-User · 06 Oktober 2019, 08:21:24

Schon, aber es macht nicht soviel Spaß, das auszutesten

.

Im Ernst: Es scheint eine Inkompabilität zwischen RF und IR zu sein, es gab an der seriellen Schnittstelle die Ausgabe einer Kernel Panic. Schade eigentlich, aber für mich kein Beinbruch. Ich werde jetzt halt nur den IR+BLE-Pfad weiter nutzen, aber von einer echten "eierlegenden" ist die Bridge damit (leider) noch weit weg, und dass das IR-Protokoll nummerisch ausgegeben wird statt (wie bei Tasmota) per Namen, ist auch nicht optimal (~~das werde ich da mal einkippen, denke ich~~ EDIT: gibt eine eindeutige Übersetzungstabelle, nicht notwendig).
Ist aber alles nicht dramatisch, tauglich ist das GW trotzdem und wegen der BT-Funktionalität wird es wohl der dauerhafte Ersatz für den IR-Tasmota werden...

(Außerdem wollte ich schon länger mal Atom/platformio ans Laufen bringen, und wenigstens das hat 100% geklappt

. Ist schon "besser" wie die Arduino-IDE).

Gruß, Beta-User

micky0867 · 04 Februar 2020, 20:02:04

Hallo,

ich habe mir gerade das aktuelle Template gezogen.
Bei "BT_scan_now" fehlt noch das "config" im Topic.

Ich habe auch mal versucht, den Ablauf (wie hier beschrieben: https://forum.fhem.de/index.php/topic,94494.msg1020790.html#msg1020790) nachzuvollziehen.
So ganz verstanden habe ich es leider nicht.
Das erste Device (hat bei mir "dummerweise" den Namen OMGFlur) versehe ich mit dem Template OpenMQTTGateway_MCU
Dies erzeugt ein neues Device mit dem Namen MQTT2_oMQTTgw_BT.
Dem könnte ich dann das Template OpenMQTTGateway_BT_scanner verpassen, hätte ich beim Namen statt OMGFlur irgendwas mit OpenMQTTGateway genommen.

Zunächst wundert mich, dass der Name MQTT2_oMQTTgw_BT scheinbar fix vergeben wird. Wäre es nicht besser, hier den Namen des Ursprungsdevices mit einzubauen?
In der Form:

Code Auswählen

..
BASE_ID/DEVNAME/BTtoMQTT/([0-9A-Z]+):.* "oMQTTgw_BT_DEVNAME"\
..

Ich habs zwar noch nicht probiert, aber wenn ich ein weiteres BT-Gateway konfiguriere, müsste es doch sonst eine Kollision geben?
Und wenn im Namen der Begriff oMQTTgw_BT "hart" eincodiert wird, könnte man im Template für OpenMQTTGateway_BT_scanner doch den Filter entsprechend anpassen:

Code Auswählen

name:OpenMQTTGateway_BT_scanner
prereq:{my @devices=devspec2array("model=OpenMQTTGateway_MCU");;return 1 if $devices[0];;return 0}
filter:TYPE=MQTT2_DEVICE:FILTER=NAME=.*oMQTTgw_BT.*

Vielleicht habe ich es aber noch nicht richtig durchschaut?