Patch für mehrere Probleme mit Topics und Payload

[hexenmeister]

Moin!

Ich habe jetzt mehrere hier im MQTT-Unterforum genannten Probleme gesammelt angegangen.
Zwar habe ich schon fast identische Versionen zum testen im "Topic mit Leerzeichen oder Doppelpunkt funktioniert nicht"-Thread angeboten, mache hier dennoch noch ein mal, da es mehr Themen betroffen sind, als nur Leerzeichen/Doppelpunkte.

Also, hier ist die Fix-Liste:

- Problem mit dem $-Zeichen in Topics
- Problem mit dem Leerzeichen in Topics (solche Topics müssen mit Anführungzeichen geschützt werden)
- Problem mit dem :-Zeichen in Topics
- Problem mit dem JSON-String als Payload
- Problem mit GUI-Zusatzparametern in publishSet (z.B. level:slider,0,1,100)
- Beim Wiederaufbau von verlorenen (bzw. manuell getrennten) Verbindungen wird jetzt ggf. gesetzte QOS-Flags für jeden Topic wieder korrekt neu gesetzt.
- Client-Hooks für client_start und client_stop

Betroffen sind zwei Dateien (00_MQTT, 10_MQTT_DEVICE), s. Anhang.

Bei mir (und paar anderen Benutzern) scheint alles korrekt zu funktionieren, dennoch sind natürlich weitere Tester immer willkommen.

Ansonsten könnten meines Erachtens die Änderungen in die RePo aufgenommen werden.

@eisler: Stephan, wie wäre es für dich bequemmer: Modul-Dateien im Ganzem, oder als Patches? Falls zweite, reicht dann ein Gesamtpatch (pro Datei natürlich), oder soll ich die Änderungen (soweit geht) voneinander trennen und Einzelpatches liefern?

Grüße
Alexander

[Beta-User]

Moin!

Gute Sache, würde vermutlich u.a. die meisten der hier erörterten Probleme lösen, um die Sidoh-Milight-Bridge voll nutzen zu können.

Hab's mir kurz angesehen, und irgendwie kann ich die Unterschiede zu den im SVN enthaltenen Module nicht recht erkennen. Sicher, dass hier die gepatchten Versionen gepostet sind?

Danke jedenfalls für die Initiative,

Beta-User

[eisler]

@hexenmeister Modul-Dateien im Ganzem, oder als Patches passt beides. Gesamtpatch pro Datei ist ok.

Grüße
Stephan

[hexenmeister]

Hab's mir kurz angesehen, und irgendwie kann ich die Unterschiede zu den im SVN enthaltenen Module nicht recht erkennen. Sicher, dass hier die gepatchten Versionen gepostet sind?

Ähm... Habe nochmals angesehen, ja, doch, sind die gepatchte Versionen. Schau mal bitte noch mal nach. Ich hänge zwischendurch mal auch Patches an.

[hexenmeister]

Und die Patch-Dateien...

[Beta-User]

Ähm... Habe nochmals angesehen, ja, doch, sind die gepatchte Versionen. Schau mal bitte noch mal nach. Ich hänge zwischendurch mal auch Patches an.

Sorry, das paßt...

Zu diesem Teil

Problem mit dem JSON-String als Payload

eine Frage:
Bedeutet das, dass man empfangssseitig nicht mehr unbedingt den Weg über expandJSON (oder was selbergestricktes) gehen muß?
Wie sieht es auf der Sendeseite aus?

EDIT: (Werde erst mal testen, was jetzt eigentlich Stand der Dinge ist, vielleicht klappt ja bereits mehr von alleine, als ich im Moment annehme... Melde mich dann ggf. wieder.).

Gruß, Beta-User

[hexenmeister]

Nein, das ermöglicht Versand von json-representation im payload. Das ging früher nicht.

[Beta-User]

Danke für die Klarstellung, das hilft jedenfalls deutlich weiter.

In Bezug auf die Milight-Bridge: Wie muß man das anwenden/einstellen, dass json verwendet werden soll bzw. welche Parameter da rein sollen? Oder läuft das automatisch?

[hexenmeister]

Nein, wir haben uns immer noch nicht verstanden. Json-string muss man immer noch selbst zusammenstellen. Nur früher gingen keine Werte in geschweiften Klammern.
Beim Thema direkte json Unterstützung bin ich mir weiterhin nicht sicher, dass das eine gute Idee wäre, das in Modul einzubauen. Dafür gibt es doch schon expand json Modul.

[Beta-User]

Dann wäre also die Frage: wie stellt man den JSON-String sendeseitig zusammen?
Ein Beispiel würde mir sehr weiterhelfen. Bei den Milights müßte was rauskommen wie {"$command":"$value"}, also {"hue":"123""}, {"command":"white_mode"} oder {"brightness":"255"}

Was expanJSON angeht: Ist schon klar, dass es das gibt, und dass es vermutlich auch wg. der rekursiven Funktionsweise besser ist, das separat zu lassen. Muß ich mich halt erst mal eindenken, aber das wird schon werden...

[hexenmeister]

Derzeit gibt es keinerlei json-Unterstützung in dem Modul. D.h. man muss schon selbst diesen irgendwie zusammensetzen und an das 'set'-Befehl übergeben.
Es wäre denkbar, eine Möglichkeit einzubauen, dass dabei eine vorher definierte Expression ausgeführt wird, die das dann zusammensetzen könnte, das wäre aber ein anderes Vorhaben, was mit dem hier nichts zu tun hätte.

[Beta-User]

OK, Danke für die Info.


Evtl. hat lufi da in dem bereits verlinkten thread schon gute Vorarbeit geleistet. Vielleicht könnt ihr euch das mal ansehen, das wäre nett.


Mobiler, kurzer Gruß,


Beta-User

[hexenmeister]

So ein String, wie dort beschrieben, kann jetzt gesendet werden (das war genau das Problem, der String wurde fälscherweise als Expression 'erkannt' und verschlückt).
Wg. dem automatischen Zusammenbau habe ich, denk' ich, das Problem noch nicht verstanden. Soll beim 'set blup' irgendwas wie '{"value":"blup"}' gesendet werden?

[Beta-User]

Hmm, das Problem mit dem Versenden war mir bisher nicht aufgefallen - das hat mit lufi's Version und auch meinen diversen Versuchen ohne Probleme geklappt.

Dann also ein Anlauf dazu, das darzustellen, wie das bei den Milights nach meinem evtl. noch unvollständigen Verständnis ist:
- Alles, was an Befehlen an den Hub gesendet wird, geht über denselben update-Topic raus, die eigentliche Info, auf welches Detail sich eine Änderung/ein Befehl bezieht, steckt also in dem JSON.
- Die Event-Map sieht z.B. so aus: /status ON:on/ /status OFF:off/
- wird jetzt ein "on" verursacht, geht an das update-topic (Text aus mosquitto_sub, dort jeweils ohne die '') ein '{"status":"ON"}', entsprechend bei Nutzung des "brightness:colorpicker,BRI,0,1,255" z.B. ein '{"brightness":"123"}'.
- Die Umsetzung erfolgt innerhalb des modifizierten Moduls schlicht, indem die bereits vorhandenen Variablen genutzt werden ($command und $value).

Die entscheidende Änderung im Code ist das hier (in der "sub set()", meine Version, ich kann nicht sagen, ob das Nebenwirkungen auf Devices hat, die das nicht brauchen...):

Code Auswählen Erweitern

if(defined($hash->{'.sendJson'}) and $hash->{'.sendJson'} ne 0) {
$value =~ s/^\s+|\s+$//g;
$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => "{\"$command\":$value}", qos => $hash->{qos}, retain => $retain);
} else {
$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $value, qos => $qos, retain => $retain);
...
Die restlichen Änderungen sind nur dazu da, das Attribut definieren zu können.

Das Vorgehen an sich, Änderungen so umzuformen, erscheint mir auch einigermaßen generisch, so dass das eigentlich auch auf andere Devices passen könnte, die JSON-Infos auf update-Topics erwarten (nur dann macht das Senden von JSON ja Sinn).

Hoffe, das jetzt halbwegs verständlich erläutert zu haben, wie gesagt, ich bin erst dabei mich überhaupt in das ganze Thema MQTT einzudenken.

Gruß, Beta-User

EDIT: Sende-Code angepaßt, Erläuterung folgt

[Beta-User]

EDIT:
Vorab: Macht das Sinn, das hier zu diskutieren, oder sollte das in einen separaten Thread?
Und ansonsten: Ist das Thema mit den Milights so spezielle, dass es tatsächlich besser wäre, dafür ein eigenes Client-Modul zu basteln?

Ansonsten noch eine Ergänzung zum Vorhergehenden:

Der Sendecode wie bereits dargestellt funtioniert zwar:

müßte was rauskommen wie {"$command":"$value"}, also {"hue":"123""}, {"command":"white_mode"} oder {"brightness":"255"}

Besser wäre aber scheinbar:
{"$command":$value}, also {"hue":123}, {"command":white_mode} oder {"brightness":255}
Hab's oben bereits angepasst. Damit scheint die Bridge genauso klar zu kommen, aber ein update aller Daten in state erfolgt teilweise nur dann, wenn keine "" um $value gesendet werden. Negative Auswirkungen scheint das nicht zu haben, ist aber auch nicht intensiv getestet.

Noch etwas Traffic, damit erkennbar wird, wie FHEM und die Bridge miteinander sprechen:

Code Auswählen Erweitern

Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/0x63C2/rgbw/4', ... (22 bytes))
{"command":night_mode}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x63C2/rgbw/4', ... (15 bytes))
{"state":"OFF"}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x63C2/rgbw/4', ... (37 bytes))
{"state":"ON","command":"night_mode"}
Client mosqsub/XXXX received PUBLISH (d0, q0, r0, m0, 'milight/states/0x63C2/rgbw/4'' ... (93 bytes))
{"state":"ON","status":"ON","level":72,"bulb_mode":"night","color":{"r":255,"g":255,"b":255}}

Evtl. könnte man das so machen, dass man die Zeichenkette mit der Anweisung, wie das im Ergebnis zusammengebaut werden soll, direkt in dem Attribut sendJson hinterlegen kann (hier also: {\"$command\":$value}).
Dann könnte das im Ergebnis evtl. so aussehen (wenn das direkt und ohne Zwischenschritte geht, sonst müßte man ggf. erst das Attribut auslesen und den Sendestring vorab in eine Variable packen):

Code Auswählen Erweitern

$msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $hash->{'.sendJson'}, qos => $hash->{qos}, retain => $retain);
Kann's ja bei Gelegenheit mal testen...

[hexenmeister]

Eher nicht, hier sind wir mit dem Thema falsch. Am besten einen neuen Thread eröffnen. Ich hätte auch schon mal eine Idee, wie man das halbwegs generisch implementieren könnte, wäre voraussichtlich nicht mal besonders aufwendig. Das wäre aber definitiv einen neue Baustelle. Und davon habe ich gerade genug. Zuerst möchte ich meine GENERIC_BRIDGE endlich mal fertigstellen.

Ich schlage vor, Du erstellst eien neuen Thread, dort könnte ich meine Vorschlag beschreiben. Dient zunächst als Merker, dann irgendwann als Testthread für die Implementierung.

[SabineT]

Das autoSubscribeReadings von Topics mit Leerzeichen dürfte noch nicht richtig funktionieren.

Folgende Topics werden empfangen (mit mosquitto_sub abgefragt):

Code Auswählen Erweitern

iobroker/rpi2/0/memory/memory total 927.22
iobroker/rpi2/0/memory/memory free 98.38
iobroker/rpi2/0/memory/memory available 164.58

autoSubscribeReadings hab ich so gesetzt:
attr ioBroker_RPI autoSubscribeReadings iobroker/rpi2/0/memory/+

die RAW definition vom device im FHEM schaut danach so aus:

Code Auswählen Erweitern

defmod ioBroker_RPI MQTT_DEVICE mqttserver
attr ioBroker_RPI IODev mqttserver
attr ioBroker_RPI autoSubscribeReadings iobroker/rpi2/0/memory/+
attr ioBroker_RPI stateFormat transmission-state
attr ioBroker_RPI subscribeReading_memory available iobroker/rpi2/0/memory/memory available

setstate ioBroker_RPI incoming publish received
setstate ioBroker_RPI 2018-04-08 07:31:00 memory available 164.58
setstate ioBroker_RPI 2018-04-08 07:31:00 memory free 98.38
setstate ioBroker_RPI 2018-04-08 07:31:00 memory total 927.22
setstate ioBroker_RPI 2018-04-08 07:31:00 transmission-state incoming publish received

Es werden also 3 Readings angelegt, allerdings mit Leerzeichen im Namen, die dazugehörigen subscribeReading Attribute sind aber nicht vorhanden bzw. falsch! Daher werden danach die Readings auch nicht upgedated.

Wenn ich die subscribeReading selber anlege und die Leerzeichen bei den Namen durch z.B. _ ersetzte und die topics in Hochkomma tuts aber richtig:

Code Auswählen Erweitern

attr ioBroker_RPI subscribeReading_memory_available 'iobroker/rpi2/0/memory/memory available'
attr ioBroker_RPI subscribeReading_memory_free 'iobroker/rpi2/0/memory/memory free'
attr ioBroker_RPI subscribeReading_memory_total 'iobroker/rpi2/0/memory/memory total'

lg, Sabine

[hexenmeister]

Stimmt, mit Leerzeichen hat autoSubscribe tatsächlich Probleme.
Da FHEM die Werte schon einzeln zerlegt an die Attr-Routine übergibt, ist das nicht ganz einfach zu umgehen. ParseParams wird meines Wissens nicht für AttrFn unterstützt, man müsste höchstens alle Werte wieder zusammen werfen und neu zerlegen. Alles mit einem nicht ganz unaufwendigen Umbau (und vor allem Test) verbunden.
Ich nutze selbst autoSubscribe nicht daher überlasse ich die Implementierung gern jemanden anderen

[SabineT]

Wenn man's weis ist das zumindest für mich kein Problem. Ich hab einfach die subscribeReading_* Attribute für dieses Device einzeln angelegt. Wollte nur darauf hinweisen und eventuell hilft es ja anderen, die in die gleiche Falle tappen zu wissen, dass autoSubscribe bei Leerzeichen in Topics halt nicht verwendet werden sollte.

Wäre aber vielleicht sinnvoll, in der Comandref darauf hinzuweisen (auch, dass das man dann die Topics in ' ' setzen sollte).

BTW:

lg, Sabine

[hexenmeister]

Alles richtig, Hinweise sind immer gut
Ich würde es mir schon annehmen, aber es sind gerade so viele unfertige Baustellen hier...

[SabineT]

Alles richtig, Hinweise sind immer gut
Ich würde es mir schon annehmen, aber es sind gerade so viele unfertige Baustellen hier...

Kein Problem. Behalte es halt im Hinterkopf, dass du das mal bei Gelegenheit in die Comandref mit aufnimmst.
Die unfertigen Baustellen sind auf jeden Fall wichtiger.
1ch weis aus eigener Erfahrung, Doku ist  oft nicht am letzten Stand, speziell wenn man mehrere Sachen gleichzeitig bearbeiten muss.

Danke jedenfalls für deine Arbeit!

lg, Sabine

[hexenmeister]

Ein kleines Fix für Log-Warnung, falls kein last-wlll definiert ist, außerdem Problem mit der Reihenfolge der Definition in fhem.cfg sollte behoben sein (Problem, wenn MQTT_DEVICE oder MQTT_BRIDGE vor dem IODev (also MQTT) definiert sind).

[hexenmeister]

Änderungen:
Automatische Anlage des 'stateFormat'-Attributes falls nicht vorhanden entfernt.
Hinweis in die Dokumentation aufgenommen, dass bei Topics mit Leerzeichen mit 'autoSubscribeReadings' nicht funktionieren.

[hexenmeister]

Und noch ein kleiner Fix bei der Verarbeitung von Topic-Matching (Betrifft $-Zeichen).

Es habes sich schon einige Änderunge angesammeln, laufen bei mir stabil, Beschwerden gab es hier auch anscheinen nicht 
@Stephan, magst Du diese in die RePo aufnehmen?

[eisler]

@hexenmeister kann ich machen. 

Grüße
Stephan

[hexenmeister]

Prima, danke! 

[Master_Nick]

Also ich kann was feststellen, ich bin mir nur unklar, ob die Herkunft hier liegt oder in der Generic Bridge..

War jetzt eine Woche unterwegs aber Sonntag 22.04. ging das nocht: Ich konnte über MQTT Temperaturvorgaben an FHEM geben und FHEM gab es ans Thermostat weiter - nun bleibt der letzte Schritt aus obwohl das Reading geändert wrid.

https://forum.fhem.de/index.php/topic,81418.msg797984.html#msg797984

[eisler]

@hexenmeister done: https://svn.fhem.de/trac/changeset?reponame=&new=16674%40trunk%2Ffhem%2FFHEM&old=16673%40trunk%2Ffhem%2FFHEM

Grüße
Stephan

[hexenmeister]

Danke

[Scotch]

Hallo Hexenmeister,

kannst du mir bitte an einem kurzen Beispiel erklären, wie ich einen JSON String von FHEM zu einem Device per MQTT übertrage.
Gruß Scotch

[hexenmeister]

MQTT-Module haben keinerlei JSON-Unterstützung. Ich selbst benutze auch kein JSON. Daher kann ich auch wenig dazu sagen.
Aber aus der Richtung FHEM sollte doch egal sein, was für ein String übertragen wird? Was genau ist das Problem?

[Scotch]

Hallo Hexenmeister,
danke für Deine Antwort.

Auf der ersten Seite hast Du doch geschriebven

...
- Problem mit dem JSON-String als Payload
...

Oder verwechsle ich da jetzt grundlegend etwas?

Mein Problem ist, das ich folgende Beispiele an einen ESP 8266 übergeben will.

{"brightness":150,"color_name":"blue","transition":"5"}

{"color_name":"green","brightness":255,"flash":"short"}

{"transition":"50","brightness":255,"effect":"rainbow"}

Das ganze soll dann die Effekte bzw. Farbe und Helligkeit von den WS 2812b LED Streifen steuern.
Das ganze ist von der Seite
https://github.com/bruhautomation/ESP-MQTT-JSON-Digital-LEDs
Nur das ich es nicht mit Home Assistant sondern per FHEM steuern möchte.
Wenn ich den Playload in MQTT.fx per Publish versende, funktioniert es.

Gruß Scotch

[hexenmeister]

Es gab Probleme mit den Geschweiften Klammern und folglich auch mit JSON-Strings. Das sollte nicht mehr sein. Eine spezielle JSON-Unterstützung ist das jedoch keineswegs.
Wie versuchst Du die Werte zu versenden und was genau funktioniert dabei nicht?

[Scotch]

Hallo Hexenmeister,

zum testen hab ich das mal so aufgebaut.

Code Auswählen Erweitern


defmod Sonoff_Switch MQTT_DEVICE
attr Test_Switch IODev myBroker
attr Test_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Test_Switch icon hue_filled_br30
attr Test_Switch publishSet {"state":"ON"} {"state":"OFF"} hello/world
attr Test_Switch room MQTT
attr Test_Switch stateFormat transmission-state
attr Test_Switch subscribeReading_Status hello/world/STATUS
attr Test_Switch webCmd ON:OFF


Wenn ich dann auf on bzw. off klicke kommen auch nur ON oder OFF an und leider nicht {"state":"ON"} bzw. {"state":"OFF"}
Gruß Scotch

[hexenmeister]

Das, was man in publishSet angeben kann, wird als mögliche 'set'-Variante gültig. Sollte auch in der Auswahlbox auf der Oberfläche so erscheinen (obwohl in diesem Fall werden Sonderzeichen sicher für Probleme sorgen). Ansonsten wird das gesendet, was du beim set angibst. Deine webCmd definiert ON und OFF. So wird das beim Klick natürlich auch gesendet. Um das zu ändern gibt es eventMap. Damit das auch in der Oberfläche  korrekt angezeit wird, muss man die Angaben als Perl-Expression mit zusätzlichen Parametern definieren. Beispiel findet man im Forum. Schnell gesucht, scheint ein Mapping von on/off auf true/false zu sein
eventMap { dev=>{ 'true'=>'on', 'false'=>'off' }, usr=>{ '^on$'=>'true', '^off$'=>'false' }, fw=>{ '^on$'=>'on', '^off$'=>'off' } }

Die Klammern musst Du in Deinem Fall natürlich noch maskieren. Sollte aber machbar sein. Zugegeben, JSON-Werte in dem FHEM zu verarbeiten ist nicht gerade bequem.

[Master_Nick]

Moin
Kann es sein, dass der fix für topics wie $online immer noch nicht im Repo ist? (Auch wenn es einige Seiten vorher sogar mit SVN Link steht...)

Habe jetzt gerade wieder ein par mal geupdatet und merke nun gerade - meine online states der Homie ESP Fraktion sind wieder verloren gegangen und werden von FHEM nicht abgeholt.

[hexenmeister]

kann eigentlich nicht sein

[Master_Nick]

Mh - ich hab hier gerade noch was anderes festgestellt... solange sag ich es liegt an meinem System...

- melde mich - :-D

[hexenmeister]

Habe jetzt im SVN nachgesehen, die Ersetzung von $-Zeichen durch Maskierte $-Zeichen ist noch drin.
Poste mal ggf. Deine Konstellation, damit ich es nachstellen kann.

[Master_Nick]

Hier das List von dem Device wo $online nicht geht (einer von alle denen mit Homie)
Habe aufm Broker mitgelauscht online isser definitiv!

Code Auswählen Erweitern

homeland/haushalt/elektrik/sonoff/sonoff-basic-1/$online true


Code Auswählen Erweitern

Internals:
   CFGFN     
   IODev      MQTT_Broker
   NAME       Sonoff_Basic_1
   NR         149
   STATE       
   TYPE       MQTT_DEVICE
   qos        *:2
   retain     *:1
   READINGS:
     2018-10-11 14:40:46   online          false
     2018-10-11 14:38:25   state           
     2018-10-11 14:40:46   transmission-state incoming publish received
   message_ids:
   publishSets:
     :
       topic      homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on/set
       values:
         true
         false
         reset
         reboot
         ota-restart
   sets:
     false     
     ota-restart
     reboot     
     reset     
     true       
   subscribe:
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/$online
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on
   subscribeExpr:
     ^homeland\/haushalt\/elektrik\/sonoff\/sonoff-basic-1\/\$online$
     ^homeland\/haushalt\/elektrik\/sonoff\/sonoff-basic-1\/switch\/on$
   subscribeQos:
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/$online 0
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on 0
   subscribeReadings:
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/$online:
       cmd       
       name       online
     homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on:
       cmd       
       name       state
Attributes:
   IODev      MQTT_Broker
   alexaName  Monitore
   alexaRoom  Arbeitszimmer
   alias      Anubis_Perepherie
   devStateIcon on:10px-kreis-gruen off:10px-kreis-rot .*:hourglass
   eventMap   { dev=>{ 'true'=>'on', 'false'=>'off' }, usr=>{ '^on$'=>'true', '^off$'=>'false' }, fw=>{ '^on$'=>'on', '^off$'=>'off' } }
   genericDeviceType outlet
   gerate     Jorin_PC
   group      Computer
   icon       it_television
   publishSet true false reset reboot ota-restart homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on/set
   qos        2
   retain     1
   room       Arbeitszimmer,Echo
   stateFormat state
   subscribeReading_online homeland/haushalt/elektrik/sonoff/sonoff-basic-1/$online
   subscribeReading_state homeland/haushalt/elektrik/sonoff/sonoff-basic-1/switch/on
   useSetExtensions 1
   userattr   gerate gerate_map structexclude
   webCmd     on:off

[Master_Nick]

Läuft alles.....

War irgendwas stranges...  Aber selbst verschuldet.