Zigbee2MQTT - Template für Thermostat

Begonnen von Snocksman, 07 Dezember 2020, 17:22:39

Vorheriges Thema - Nächstes Thema

Snocksman

Jetzt sieht das ganze so aus:

defmod MQTT2_zigbee_0xbc33acfffe45850a MQTT2_DEVICE zigbee_0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_0xbc33acfffe45850a devStateIcon LOCKED:secur_lock:child_lock+UNLOCK UNLOCKED:secur_open:child_lock+LOCK
attr MQTT2_zigbee_0xbc33acfffe45850a devicetopic zigbee2mqtt/0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a jsonMap current_heating_setpoint:desired-temp local_temperature:measured-temp
attr MQTT2_zigbee_0xbc33acfffe45850a readingList zigbee2mqtt/0xbc33acfffe45850a:.* { my %h;; my $temp = $EVENT;; $temp =~ s/,?("(holidays|workdays)":.([^]]+))./$h{$2}=$3/ge;; $EVENT =~ s/,?("(holidays|workdays)":.([^]]+)).//g;; my $h2 = json2nameValue($EVENT,'',$JSONMAP);; %h = (%h,%$h2);; \%h }
attr MQTT2_zigbee_0xbc33acfffe45850a room MQTT2_DEVICE
attr MQTT2_zigbee_0xbc33acfffe45850a setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"current_heating_setpoint": $EVTPART1 }\
  child_lock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}
attr MQTT2_zigbee_0xbc33acfffe45850a stateFormat child_lock

setstate MQTT2_zigbee_0xbc33acfffe45850a UNLOCKED
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 auto_lock MANUAL
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 away_mode OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 away_preset_days 1
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 away_preset_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 boost_time 300
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 child_lock UNLOCKED
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 comfort_temperature 20
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 desired-temp 27.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 eco_temperature 15
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 force normal
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 holidays {"hour":134,"minute":0,"temperature":20},{"hour":8,"minute":0,"temperature":15},{"hour":11,"minute":30,"temperature":15},{"hour":12,"minute":30,"temperature":15},{"hour":17,"minute":30,"temperature":20},{"hour":22,"minute":0,"temperature":15}
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 linkquality 214
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 local_temperature_calibration -1.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 max_temperature 35
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 measured-temp 22.0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 min_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 position 0
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 preset manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:02:26 state desired-temp
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 system_mode manual
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 week 5+2
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 window_detection OFF
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 window_detection_params_minutes 10
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 window_detection_params_temperature 5
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 13:03:57 workdays {"hour":6,"minute":0,"temperature":20},{"hour":8,"minute":0,"temperature":15},{"hour":11,"minute":30,"temperature":15},{"hour":12,"minute":30,"temperature":15},{"hour":17,"minute":30,"temperature":20},{"hour":22,"minute":0,"temperature":15}

Beta-User

Sieht doch gut aus, oder?

Jetzt wäre noch zu klären, was das im einzelnen zu bedeuten hat, jsonMap, stateFormat etc. entsprechend zu erweitern, und dann schauen wir mal, wie wir weekprofile ggf. ins Boot holen können...?
Für's erste also erst mal versuchen, das Teil in einen Automatik-Modus zu überführen und das alles mal zu loggen (und zu visualisieren), ob es Sinn ergibt bzw. welchen.

Bitte auch mal rund um diesen Beitrag etwas rumlesen: https://forum.fhem.de/index.php/topic,97989.msg1099767.html#msg1099767. Ist zwar vermutlich kaum verständlich, aber im Kern geht es auch darum, dass man (mit jsonMap) "gute" Readingsnamen generiert, die dann ggf. auch nahtlos in die Sprachsteuerungswelt passen. Insbesondere klingt ggf. "system_mode" danach, als sollte man es kurz und bündig "mode" nennen. Weiß aber noch nicht, ob die Inhalte dann dazu passen.
(es gab irgendwo da verlinkt auch eine Seite, wo die ganzen Mapping-Werte (=Readings-Inhalte, nicht die Namen) erläutert waren; ggf. wäre es hilfreich, das noch zu unserer Materialsammlung hier zu verlinken, falls jemand drüberstolpert?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

Interessant fände ich auch noch folgendes:
- Boost Funktion (Da hier scheinbar ein Zeitwert mitgegeben werden muss... Das müsste dann irgendwas in Richtung set boost 300 werden...) Dabei wird das Thermostat dann für die angegebene Zeit voll aufgedreht.
- Das devStateIcon scheint noch nicht ganz zu funktionieren... Bei child_lock UNLOCK sieht man das offene Schloss, bei LOCK wird nur LOCKED angezeigt, anstelle des Schlosses.
- Schön wäre noch, die aktuell gemessene Temperatur irgendwie anzuzeigen.

Was mir sonst noch aufgefallen ist: Wenn sich nichts ändert scheint das Thermostat in so eine Art Sleep-Mode zu fallen... Es sendet dann keine Werte mehr, bis man es entweder am Gerät, oder per FHEM einmal "anstuppst"...

Beta-User

#18
Bzgl. boost:

Da auch andere Thermostate diesen Befehl kennen, würde ich ihn im attrTemplate so lassen, aber dann eben in der payload den (üblichen) Wert fest vorgeben; die 5 Min. scheinen sowas wie ein Standard zu sein. Wer es dann anders mag, kann ja daran rumschrauben.

Eventuell kann man ja einen allg. "userset"-setter vorsehen, der dann einfach beliebigen Payload entgegennimmt. Wäre zumindest zum Testen eh' gut, weil man dann auch das genaue Format für Temperaturlisten austesten könnte.

Das devStateIcon/stateFormat war bewußt unvollständig, dachte, "jemand" hätte vielleicht Freude am Knobeln; es ist keine große Kunst, via mehrzeiligem stateFormat alles mögliche anzuzeigen (und Icons dazu anzeigen lassen); eventuell kannst du auch meinen Code aus https://forum.fhem.de/index.php/topic,97430.msg906576.html#msg906576 ausschlachten, das ist dann aber Perl, und hier ginge es ggf. etwas transparenter mit devStateIcon/stateFormat, daher habe ich das erst mal so in den Raum geworfen.

Zitat von: Snocksman am 10 Dezember 2020, 14:28:11
Was mir sonst noch aufgefallen ist: Wenn sich nichts ändert scheint das Thermostat in so eine Art Sleep-Mode zu fallen... Es sendet dann keine Werte mehr, bis man es entweder am Gerät, oder per FHEM einmal "anstuppst"...
Hm, das kann zwei Ursachen haben: Es gibt nichts zu berichten, dann wäre das ok (keine wesentliche Änderung der gemessenen Temperatur oder der Soll-Temperatur), oder man muss es tatsächlich aktiv abfragen.

In letzterem Fall wäre der Weg, ein get abzusetzen:
Zitatlocal_temperature: Current temperature measured on the device (in °C). To read send a message to zigbee2mqtt/FRIENDLY_NAME/get with payload {"local_temperature": ""}
.Bereite mal einen getList-Eintrag für die measured-temp vor ;) . Den rufen wir dann per periodicCmd auf (alle 60 Minuten?).

Ansonsten habe ich etwas gebastelt und kann mit leicht ergänztem "weekprofile"-Code und ein paar Attributen und etwas Perl dann schon mal sowas hier erzeugen:
Zitatdefmod MQTT2_zigbee_0xbc33acfffe45850a MQTT2_DEVICE zigbee_0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a userattr weekprofile
attr MQTT2_zigbee_0xbc33acfffe45850a IODev m2server
attr MQTT2_zigbee_0xbc33acfffe45850a devStateIcon LOCKED:secur_lock:child_lock+UNLOCK UNLOCKED:secur_open:child_lock+LOCK
attr MQTT2_zigbee_0xbc33acfffe45850a devicetopic zigbee2mqtt/0xbc33acfffe45850a
attr MQTT2_zigbee_0xbc33acfffe45850a jsonMap current_heating_setpoint:desired-temp local_temperature:measured-temp
attr MQTT2_zigbee_0xbc33acfffe45850a readingList $DEVICETOPIC:.* { my %h;; my $temp = $EVENT;; $temp =~ s/,?("(holidays|workdays)":.([^]]+))./$h{$2}=$3/ge;; $EVENT =~ s/,?("(holidays|workdays)":.([^]]+)).//g;; my $h2 = json2nameValue($EVENT,'',$JSONMAP);; %h = (%h,%$h2);; \%h }\
$DEVICETOPIC/set:.* set
attr MQTT2_zigbee_0xbc33acfffe45850a room MQTT2_DEVICE
attr MQTT2_zigbee_0xbc33acfffe45850a setList desired-temp:slider,5.0,0.5,30.0,1 $DEVICETOPIC/set {"current_heating_setpoint": $EVTPART1 }\
  child_lock:LOCK,UNLOCK $DEVICETOPIC/set {"child_lock": "$EVTPART1"}\
  weekprofile { FHEM::attrT_z2m_thermostat_Utils::z2t_send_weekprofile($NAME, $EVTPART1) }
attr MQTT2_zigbee_0xbc33acfffe45850a stateFormat child_lock
attr MQTT2_zigbee_0xbc33acfffe45850a weekprofile zigbeetest

[...]
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 15:24:33 set
{"holidays":[{"hour":120,"minute":0,"temperature":18.0},{"hour":144,"minute":0,"temperature":18.0}],"workdays":[{"hour":0,"minute":0,"temperature":5.5,"hour":10,"minute":0,"temperature":19.0,"hour":12,"minute":0,"temperature":18.0},{"hour":24,"minute":0,"temperature":5.5,"hour":34,"minute":0,"temperature":19.0,"hour":36,"minute":0,"temperature":18.0},{"hour":48,"minute":0,"temperature":5.5,"hour":58,"minute":0,"temperature":19.0,"hour":60,"minute":0,"temperature":18.0},{"hour":72,"minute":0,"temperature":5.5,"hour":82,"minute":0,"temperature":19.0,"hour":84,"minute":0,"temperature":18.0},{"hour":96,"minute":0,"temperature":5.5,"hour":106,"minute":0,"temperature":19.0,"hour":108,"minute":0,"temperature":18.0}]}
setstate MQTT2_zigbee_0xbc33acfffe45850a 2020-12-10 15:24:33 state weekprofile

Ausgelöst habe ich das Reading (und den passenden publish, daher VORSICHT!) über das Setzen eines Topics an einem weekprofile-Device...

Ist noch WIP, aber hier mal die betreffenden beiden Codebausteinchen, die es dazu braucht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

Mir ist noch etwas sehr seltsames bei dem Thermostat aufgefallen... Ich wollte das Teil wirklich mal an einem Heizkörper montieren und händisch ein Wochenprogramm eingeben, dabei ist mir aufgefallen, dass scheinbar bei jeder Kommunikation mit FHEM die Uhrzeit des Thermostats wieder auf 06:28am zurückgesetzt wird; Sie läuft dann bis zur nächsten Kommunikation weiter und dann zack wieder zurück auf 06:28am.

Beta-User

...irgendwie hatte mich schon gewundert, dass bei https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html nirgends was zum Thema Uhrzeit/Datum zu finden ist...

Kannst du mal schauen, ob es dazu irgendwo bei zigbee2mqtt.io eine Doku gibt? Vermute, man muss immer einen aktuellen Timestamp mitgeben, wenn man mit Wochenplänen arbeitet.
Bekommst du da (irgendwann) irgendwas, wenn du das am Thermostaten einstellst?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

#21
Zur Info: Den Part mit den Wochenplänen habe ich noch gar nicht drin. Das Rücksetzen der Uhrzeit scheint bei jeglicher Kommunikation mit FHEM zu passieren, auch wenn ich nur am Thermostat etwas umstelle, z.B. die Solltemperatur.

Aber das hier könnte evtl. etwas sein: https://github.com/Koenkk/zigbee2mqtt/issues/2586 Sieht zumindest nach dem Problem aus...

Beta-User

Nach meinem Verständnis addressiert dieser Issue was anderes, da war nach dem Empfangszeitpunkt auf dem Coordinator gefragt.

Was wir hier brauchen ist eher vergleichbar mit dem hier:
Zitat von: dominik am 06 März 2020, 15:36:14
Die Werte sind jedoch nicht korrekt. Zuerst muss ich die aktuelle Uhrzeit an das Device per BLE schicken und dann bekomme ich als Notification die richtige Antwort zurueck. (Mach ich aktuell ueber gatttool --char-write-req .... --listen).
Es ginge also darum, eine Message mit der aktuellen Uhrzeit zu senden bzw. diesen (automatisch?) eben immer (oder nur einmalig?) mit allem anderen an den passenden Endpunkt zu senden.
Dazu passend: https://github.com/Koenkk/zigbee-herdsman-converters/pull/1730/files - da steht drin, was es ausser 2+5 noch so gibt, und es gibt eine neue Funktion "setLocalTime".

Jetzt müsste man noch noch rausfinden, wie die aufzurufen ist bzw. warum die nicht automatisch mit gesendet wird...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dcboy

#23
Zu dem Zeitthema habe ich in den Issues von z2m folgendes gefunden:
https://github.com/Koenkk/zigbee2mqtt/issues/4456

Hier heisst es, dass die Firmware wohl das Problem hat und geupdatet werden müsste. Leider geht das wohl nur über das TuYa Gateway samt dazugehöriger App...

Beta-User

Hmm, Danke für's recherchieren.
Ist natürlich schwierig, wenn die firmware nicht mitspielt... Unklar ist mir allerdings, warum das nur mit dem Original-GW gehen sollte, wenn (!) man eine unverschlüsselte firmware-file haben würde. Der update-Mechanismus selbst sollte eigentlich soweit standardisiert sein, dass es prinzipiell mit jedem Coordinator gehen sollte.
Aber na ja, da kenne ich mich auch nicht tief genug aus.

Dann würde ich vorschlagen, dass ihr entweder die Dinger zurückschickt oder auf ein Einsehen des Herstellers hofft und erst mal die Steuerung über FHEM macht ohne das (direkte) weekprofile-feature.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

Ne, für meinen Teil werde ich die Dinger nicht zurückschicken... Dann muss FHEM das Wochenprogramm halt abbilden. Ich habe trotzdem gerade nochmal getestet, wie sich das ganze mit der deConz Software verhält; da ist es aber genau so.
Ich habe mir aber gerade mal so ein Tuya-Gateway bestellt... Mal schauen, wie es dann nach einem Firmwareupdate aussieht.
Wäre aber schön, wenn wir die Boost Funktion noch hinbekommen würden.

Beta-User

{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
Die boost-Zeit scheint auf dem Thermostat eingestellt zu sein, das scheint ein simpler "modus"-Command zu sein.
Testet bitte mal das betreffende neue attrTemplate aus. Ist noch nicht alles drin, was bei https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html zu finden ist, aber so sollte z.B. alle 55 Min. die measured-temp ausgelesen werden.

Ansonsten habe ich das mit der Kindersicherung noch umbenannt, angelehnt an die Benennung bei Homematic. Falls jemand was besseres einfällt: bitte melden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

Bei dem neuen Template funktioniert leider ganz viel noch nicht...

Was geht:
- Aktuell gemessene Temperatur wird ausgelesen und angezeigt

Was geht nicht:
- Setzen der Soll-Temperatur
- Child_Lock
- Batteriestatus in % (aber da vermute ich eh, dass der Wert vom Thermostat gar nicht übergeben wird.)

Im zigbee2mqtt Log stehen auch ein paar Meldungen:

Bei set Kommandos:

Dez 12 20:06:35 FHEM-Server npm[3504]: zigbee-herdsman-converters:tuyaThermostat: NOT RECOGNIZED DP #1293 with data {"type":"Buffer","data":[0]}

Bei get Kommandos:

Dez 12 20:09:03 FHEM-Server npm[3504]: Zigbee2MQTT:error 2020-12-12 20:09:03: Invalid JSON '{"current_heating_setpoint": ""} 5', skipping...

Beta-User

Hmm, Kleinigkeiten habe ich jetzt nochmal geändert, aber warum z.B. das mit der Soll-Temperatur nicht klappen soll, erschließt sich mir noch nicht so recht.

So wie es jetzt ist, müsste eigentlich jeweils genau das als publish rausgehen, was in https://www.zigbee2mqtt.io/devices/TS0601_thermostat.html die Vorgabe ist.
Bitte also erst mal checken, ob das der Fall ist - und wenn nicht, bitte auch ein RAW hier posten, von dem, was das attrTemplate erstellt bzw. (detailierte) Korrekturvorschläge machen, wenn es offensichtliche Dinge sind, entweder als attrTemplate-Code oder eben durch Posten eines funktionierenden Devices (RAW-Code).

Wird korrekt gepublisht, liegt das Problem entweder in der Doku (=> selber testen und ggf. Korrekturvorschläge bei zigbee2mqtt.io einkippen), oder es ist noch tieferliegender bei der Umsetzung innerhalb zigbee-herdsman (oder es ist ein firmwareproblem). Da können wir dann in beiden Fällen via attrTemplate leider gar mehr eingreifen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Snocksman

#29
Ich scheine da aber plötzlich auch generell Probleme zu haben... Ich habe noch einen Zigbee Helligkeitssensor, der auch nicht mehr mitspielen möchte...  :-\   Wie kann ich denn generell Devices unpairen (am besten aus FHEM heraus) ? Ich würde gerne mal einfach alle Devices unpairen und bei null anfangen. Aber wenn ich die einfach aus FHEM lösche, kommen die per zigbee2mqtt sofort wieder rein (sogar wenn die Devices ausgeschaltet sind).

OK, ich habe jetzt mal ein Backup zurückgespielt und den Conbee Stick zurückgesetzt und nun läuft wieder alles bis auf das Thermostat. Wenn ich das Template anwenden möchte bekomme ich immer folgenden Fehler:

Unknown command x_send_set_payload:textField, try help.
<html><input type='hidden' value='set MQTT2_zigbee_0xbc33acfffe45850a attrTemplate speechcontrol_alexa_specials'><p>Specify the unknown parameters for speechcontrol_alexa_specials:</p><table class='block wide'><tr><td>Set a new alexaName</td><td><input type='radio' name='s' value='RADIO_SETalexaNAME'></tr><tr><td>Leave alexaName attribute empty</td><td><input type='radio' name='s' value='RADIO_DoNotSetalexaName'></tr><tr><td>Discard genericDeviceType attribute</td><td><input type='radio' name='s' value='RADIO_Delete_gDT'></tr><tr><td>Skipp setting speech controll specific attributes</td><td><input type='radio' name='s' value='RADIO_SKIPP_SCONTROLL'></tr></table><script>
          setTimeout(function(){
            $("#FW_okDialog input[type=radio]").first().prop("checked",true);
            $("#FW_okDialog").parent().find("button").css("display","block");
            $("#FW_okDialog").parent().find(".ui-dialog-buttonpane button")
            .unbind("click").click(function(){
              var cmd;
              $("#FW_okDialog input").each(function(){
                var t=$(this).attr("type");
                if(t=="hidden") cmd = $(this).val();
                if(t=="text")  cmd +=" "+$(this).attr("name")+"="+$(this).val();
                if(t=="radio") cmd +=" "+$(this).val()+"="+
                                          ($(this).prop("checked") ? 1:0);
              });
              FW_cmd(FW_root+"?cmd="+encodeURIComponent(cmd)+"&XHR=1",
              function(resp){
                if(resp) {
                  if(!resp.match(/^<html>[\s\S]*<\/html>/))
                    resp = "<pre>"+resp+"</pre>";
                  return FW_okDialog(resp);
                }
                location.reload()
              });
              $("#FW_okDialog").remove();
            })}, 100);
         </script>
       </html>