MQTT

Kritiken, neue Ideen, Verbesserungen, alles gibt uns die Möglichkeit die Produkte weiter zu entwickeln. Wir nehmen jeden Vorschlag ernst. Reviews, new ideas, improvements, everything gives us the opportunity to develop the products further. We take every suggestion seriously.
Groej
Beiträge: 4
Registriert: Sonntag 19. April 2009, 07:50

MQTT

Beitrag von Groej » Montag 23. April 2018, 15:50

Guten Tag,

ich mache seit einiger Zeit jetzt viel mit FHEM. Konnte die HUT auch schon erfolgreich einbinden. Zwar etwas umständich über HTTP aber gehts schon.
Wäre es möglich MQTT zu implimentieren? Nur eine Idee bzw. Anregung.

MfG

Jörg

andy
Administrator
Beiträge: 483
Registriert: Dienstag 15. Januar 2008, 11:51
Wohnort: Düsseldorf
Kontaktdaten:

Re: MQTT

Beitrag von andy » Montag 23. April 2018, 18:55

Guten Tag Jörg,

MQTT wäre wahrscheinlich möglich (müsste getestet werden) aber die Nachfrage danach ist nicht vorhanden und wir wollen die Ressourcen schonen.

Danke für die Anregung.

LG Andy

andy
Administrator
Beiträge: 483
Registriert: Dienstag 15. Januar 2008, 11:51
Wohnort: Düsseldorf
Kontaktdaten:

Re: MQTT

Beitrag von andy » Dienstag 24. April 2018, 10:50

Hallo Jörg,

Wie es meistens so ist, es gab eine andere Anfrage nach MQTT.
Wir glauben die User treffen sich ab und zu beim Stammtisch :)

Würde es reichen, zu dem Broker:

NET-H ;192.168.188.87;NET - Power Control;1491485194;19;h;6.1;25.3
Nr.1;0;0;Nr.2;1;1;Nr.3;0;0;Nr.4;1;0;Nr.5;0;0;Nr.6;1;0;Nr.7;0;0;Nr.8;1;0;
IO-1;0;0;IO-2;0;0;IO-3;0;0;IO-4;0;0;IO-5;0;0;IO-6;0;0;IO-7;0;0;IO-8;0;0;
s;21.91;41.2;8;

als QoS=0 auf Port 1883 zu senden?

LG Andy

Groej
Beiträge: 4
Registriert: Sonntag 19. April 2009, 07:50

Re: MQTT

Beitrag von Groej » Mittwoch 16. Mai 2018, 17:25

Hallo,

sorry ich hab heute erst die Benachrichtigung bekommen das hier was geschrieben wurde.

Ich weiß leider nicht wie genau MQTT intern funktioniert und daher kann ich Dir leider nicht sagen ob das reichen würde. Wichtig wäre das man den String für Subscribe und Publish jeweils variable eintragen könnte. Also das man den Befehl über den Subscribe String an das Gerät senden kann und über den Publish String die Schaltbestätigung bekommt als Rückmeldung. Den Port für MQTT frei zu wählen wäre auch super aber ich glaube das fast alle auf dem Standard Port arbeiten.

Gruß

Jörg

elRadish
Beiträge: 10
Registriert: Mittwoch 4. September 2019, 14:09

Re: MQTT

Beitrag von elRadish » Freitag 19. März 2021, 18:43

Hallo,
wir könnten das auch gebrauchen - und es wäre durchaus ein Argument, die Anel-Serie noch in weiteren Installationen einzusetzen.
NET-H ;192.168.188.87;NET - Power Control;1491485194;19;h;6.1;25.3
Nr.1;0;0;Nr.2;1;1;Nr.3;0;0;Nr.4;1;0;Nr.5;0;0;Nr.6;1;0;Nr.7;0;0;Nr.8;1;0;
IO-1;0;0;IO-2;0;0;IO-3;0;0;IO-4;0;0;IO-5;0;0;IO-6;0;0;IO-7;0;0;IO-8;0;0;
s;21.91;41.2;8;

als QoS=0 auf Port 1883 zu senden?
Das würde nicht reichen. Man müsste für jedes Gerät mind. folgendes festlegen können:

- Broker IP / DNS-name
- Geräte-Topic

Dann könnte man unter GeräteTopic/1 z.b. per "On" "Off" die Dose schalten.
Wenn man das retained macht, könnte es auch gleichzeitig als Status dienen, wenn es immer synchron zum Schaltzustand gehalten wird.

Besonders für die Einbindung in OpenHAB wäre das super, das "offizielle" Binding ist ja veraltet und die Steuerung per http eher umständlich.

dan1-de
Beiträge: 2
Registriert: Montag 22. Februar 2021, 20:55

Re: MQTT

Beitrag von dan1-de » Dienstag 30. März 2021, 19:52

Hi,

ich habe mir schon vor einiger Zeit einen Adapter geschrieben, von dem Anel UDP Protokoll auf MQTT.
Programm ist in C# mit dotnet core geschrieben. Läuft daher in der Console auf Windows und auch Linux (inkl. Raspberry).
Evtl. könnte das jemandem weiterhelfen.

Es kann der Mqtt Broker (inkl. SSL on/off) und 1-x Hut's konfiguriert werden.
Ist nur mit HUT getestet, sollte aber normalerweise auch mit den anderen ANEL Geräten funktionieren.

Es funktioniert wie folgt:
Nachrichten die per UDP kommen (Status updates) werden über MQTT weitergeleitet.
Nachrichten die über MQTT kommen, werden über UDP an das entsprechende Gerät gesendet.

Struktur ist nicht ganz MQTT konform, aber ich wollte es so für meinen Zweck.
Habe das ganze mit einer selbst entwickelten Android App genutzt.

Hier kurz die API/MQTT Nachrichten:

Topic:
relais/status/onlinestatus: Informationen, ob der Raspberry/PC, auf dem der Adapter läuft verbunden ist.
Beispiel:
{"RaspberryOnline": true}


Topic:
relais/status: Enthält ein JSON Array mit allen Geräten (wird bei jeder neuen UDP Nachricht aktualisiert und mit "retained"-flag gesendet.)
Beispiel:
[
{
"StatusTimestamp": "30/03/2021 20:04:06",
"Device": "NET-PwrCtrl",
"DeviceName": "NET-CONTROL-XXX",
"DeviceIp": "X.X.X.X",
"DeviceNetmask": "X.X.X.X",
"DeviceGateway": "X.X.X.X",
"DeviceMac": "XX:XX:XX:XX:XX:XX",
"RelaisState": [
{
"RelaisNumber": 1,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 2,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 3,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 4,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 5,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 6,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 7,
"RelaisName": "XX",
"Status": 0
},
{
"RelaisNumber": 8,
"RelaisName": "XX",
"Status": 1
}
],
"IOState": [
{
"IoNumber": 1,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 2,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 3,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 4,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 5,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 6,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 7,
"IOName": "XX",
"IODirection": 1,
"Status": 1
},
{
"IoNumber": 8,
"IOName": "XX",
"IODirection": 1,
"Status": 1
}
],
"LockedSockets": "0",
"HttpPort": "80",
"DeviceTemperature": "23.2 °C",
"DeviceFirmeware": "NET-PWRCTRL_06.5"
}]

Nun zur Steuerung. Diese ist etwas umständlicher, aber man bekommt dafür ein Feedback, ob der Vorgang funktioniert hat.


Man sendet eine Nachricht an das Topic:
relais/control/command
Beispiel:
{"MqttClientId":"client-bvbx80pekj6","RelaisId":8,"Command":0,"HUTDeviceIp":"XXX"}
Anhand der IP sucht der Adapter dann das richtige Gerät, zu dem er die Nachricht per UDP sendet.

Als Antwort bekommt man vom Adapter eine Nachricht über Mqtt auf einem speziellen Topic, das anhand der Client-ID generiert wird.
Auf dieses muss man natürlich vor dem Absenden des commands subscriben. Die Client ID weiß man aber im Client.
Beispiel:
Topic:
relais/control/command/commandresponse/client-bvbx80pekj6/
Beispiel:
{
"success": true,
"message": "Success"
}

Ich habe den Adapter angehangen, falls jemand Interesse hat. Voraussetzung ist dotnet core >=2.1.
Auf Rasperrys mit ARMv6 CPU (RPI 1,2, Zero W) muss mono statt dotnet core verwendet werden. Läuft aber dann genauso.
Vor dem Start müssen die Konfigurationen im Ordner "config" entsprechend angepasst werden.
Start dann mit "dotnet ANELRelaisControlNetCore.dll"

Mqtt Broker gibts zum Beispiel gratis bei "CloudMqtt".


Ich habe aktuell nicht geplant, den Adapter weiterzuentwickeln. War nur ein Versuch in Verbindung mit der APP, um ein Feedback anzeigen zu können, ob der Vorgang funktioniert hat.
Ist aktuell auch nur für die Steuerung von Relais vorgesehen. Keine IO's.
Ich konzentriere mich derzeit auf iOBroker.

Viele Grüße
Daniel
Dateianhänge
ANELRelaisControlNetCore.zip
(289.34 KiB) 58-mal heruntergeladen

Antworten