Hallo,
mir ist eben aufgefallen, dass bei meinen IT-Devices (Steckdosen) der Wert für STATE im Reading immer auf "ON" steht, wogegen im Internal-STATE der Wert immer korrekt angezeigt wird.
Anm.: ich benutze die a-culfw mit Selbstbau-CUL
Ist das nur bei mir so?
Gruß
Blueberry63
eigentlich ist das reading state und das internal STATE vom wert gleich. sollte dein reading auch STATE und nicht state (man beachte groß und kleinschriebung)sein würde ich es mal löschen (deletereading meinedose STATE). es sollte nach dem löschen richtig angelegt werden wenn wieder geschaltet wird
@chris1284
Der Reading-Name war "state" (kleingeschrieben), ich habe das Reading aber trotzdem mal gelöscht und es wurde nach einem Schaltvorgang auch wieder angelegt. Allerdings ist der Wert jetzt fest "0" ??!!
Hat das etwas mit der a-culfw zu tun? Dadurch wurde das Device ja automatisch anglegt.
Gruß
Blueberry63
dnke ich nicht, setzte ausschließlich die a-culf ein und kann dieses verhalten nicht nachvollziehen. fhem aktuell ? ggf update machen, device löschen und neu anlegen lassen. hast du evtl andere attribute gesetzt (stateformat zb)?
@chris1284
die Devices für die IT-Steckdosen musste ich manuell anlegen, weil sie nicht automatisch erkannt worden sind (wogegen das mit den billigen Funksteckdosen ohne Probleme funktioniert hat - dort stimmen die beiden "States" auch überein). Ich habe das jetzt nochmal wiederholt (gelöscht+neu angelegt), aber das Problem besteht weiterhin: "state" in den Readings ist fest "0".
Ein "stateformat" verwende ich nicht.
Das ist alles ein bisschen seltsam...
Gruß
Blueberry63
Ich habe nochmal etwas einiges getestet und bin mir sicher, daß das Reading bei meinen IT-Devices (IT-1500) nicht aktualisiert wird. Man kann den Wert z.Bsp. manuell setzen und danch wird er nicht mehr verändert. Gibt es vielleicht bei IT-Dveices mit Protokoll-Version 3 ein Problem, denn die Baumarktsteckdosen mit Protokoll V1 funktionieren normal?
Hier meine Device-Definition:
define STD_I1_FLURU IT 00110010010001110011110010 0 0000
attr STD_I1_FLURU IODev cul433
attr STD_I1_FLURU model itswitch
Könnte mal einer der Spezialisten für IT sich der Sache annehmen?
Gruß
Blueberry63
Ich habe noch eine Info: wenn ich "Model=itdimmer" setze, dann wird das reading "state" richtig aktualisiert??!!
Meine Kenntnisse reichen leider nicht aus, um den Fehler in "10_IT.pm" zu finden, aber ich glaube es liegt im Bereich ab Zeile 350.
Gruß
Blueberry63
Hallo,
habe ich mein Problem im falschen Bereich gestellt? Gibt es einen anderen Bereich, um Fehler zu melden?
Gruß
Blueberry63
P.S.: Ich komme mit einem geänderten "Model" zurecht (s.u.).
Ich glaube schon, dass Du die Frage im richtigen Bereich gestellt hast. Ich ärgere mich übrigens auch mit dieser Angelegenheit herum.
Bei der manuellen Kategorisierung "itdimmer" oder "itremote" verliert man leider auch die Möglichkeit, den Zustand manuell per SET-Befehl zu korrigieren. Da das Intertechno / Elro HomeEasy / KAKU ein unidirektionales Übertragungsprotokoll ist, kann man den Zustand der Sender oder Empfänger nicht zeitunabhängig abfragen, sondern nur hoffen, dass die Befehle auch korrekt ausgeführt wurden. Leider liegt das am Übertragungsprinzip. Andererseits sind die Anschaffungskosten der Aktoren sehr niedrig...
Wer mehr Kontrolle/Sicherheit will, muss leider auf die teureren, bidirektionen Geräte wie beispielsweise von ELV Homematic ausweichen.
Wenn unidirektionale Geräte von Intertechno und Co. bestimmte Befehle "verschlucken", also aufgrund von Störungen oder zeitgleichem Senden anderer Intertechno-Geräte nicht ausführen, dann sieht man zwar im Web-Interface von FHEM den gewollten Zustand, aber nicht denjenigen, der tatsächlich stattfindet.
Ich habe in meine Programmierung mittlerweile Abfangroutinen eingebaut, um in gewissen Zeitabständen den Zustand per SET-Befehl auf einen plausiblen Zustand zurückzusetzen.
z.B. Ab 02:00 Uhr nachts werden bestimmte Aktoren einfach ausgeschaltet, egal was vorher irgendwo gesteuert wurde. Beim Flur-Dimmer habe ich sogar stündlich ein Zwangs-Off definiert, um bei Nichtansprechen des Bewegungsmelders den Zustand wieder zu definieren. (Ausnahme Fernseher, weil eventuell eine Video-Aufzeichnung stattfinden könnte).
Beim Dimmen ist es besonders ekelig: Ist der Zustand versehentlich on (weil der Off-Abschaltbefehl entgegen FHEM-Webinterface missachtet wurde), dann startet ein Dimmer-Empfänger von Intertechno immer den Dimmerlauf (Dimup und Dimdown), was das Flurlicht in eine Disco verwandelt. Da dieser Fehler nur sporadisch auftritt, ist der stündliche Zwangs-Off ein probates Mittel, um Ruhe in die Angelegenheit zu bekommen.
P.S. Bitte wegen den Antwortzeiten nicht böse sein. Wir sind hier in einem Austausch-Forum von Gleichgesinnten. Modul-Programmierung orientiert sich sicherlich an Bedürfnissen der Nutzer, ist aber prinzipiell "ehrenamtlich" also selten mit finanzieller Kompensation verbunden. Großen Dank gilt den Intertechno-Spezialisten - vielleicht nehmen die sich dieser Problematik an. 8).
ich denke, der fehler liegt in der if anweisung ab zeile 268 350. dort wird auf V3 geprüft. wenn aber V3 wahr ist, wird der status nur für model=itdimmer gesetzt. alle anderen modelle fallen durch. ergänze doch mal den zusätzlichen else-teil, wie hier und teste:
if ($hash->{READINGS}{protocol}{VAL} eq "V3") {
if( AttrVal($name, "model", "") eq "itdimmer" ) {
if ($v eq "on") {
$hash->{READINGS}{dim}{VAL} = "100";
$lh->{READINGS}{state}{VAL} = "on";
} elsif ($v eq "off") {
$hash->{READINGS}{dim}{VAL} = "0";
$lh->{READINGS}{state}{VAL} = "off";
} else {
if ($v eq "dim100%") {
$lh->{STATE} = "on";
$lh->{READINGS}{state}{VAL} = "on";
} elsif ($v eq "dim00%") {
$lh->{STATE} = "off";
$lh->{READINGS}{state}{VAL} = "off";
} else {
$lh->{STATE} = $v;
$lh->{READINGS}{state}{VAL} = $v;
}
}
} else {
$lh->{READINGS}{state}{VAL} = $v;
}
} else {
$lh->{READINGS}{state}{VAL} = $v;
}
edit: meine version war schon älter. in der neuesten version ist es, wie du schon sagtest, ab zeile 350.
gruss frank
@Frank
das war es: jetzt wird das Reading "state" richtig gesetzt!
:)
DANKE!
Gruß
Blueberry63
dann muss es nur noch wer "fest" einbauen.
Mit dem heutigen (30.06.) Update von 10_IT ist der Fehler aber nicht behoben...
Gruß
Blueberry63
weil der maintainer vom modul http://fhem.de/MAINTAINER.txt dancer0705 und bjoernh hiervon sicher nichts mitgekommen haben
Hallo Bjoern,
auch mit dem heutigen Update ist es noch nicht richtig umgesetzt.
Nach dem Block für "itdimmer" müssen die Zeilen bis zum Ende der Subroutine so aussehen:
else {
$lh->{READINGS}{state}{VAL} = $v;
}
} else {
$lh->{READINGS}{state}{VAL} = $v;
}
}
return $ret;
}
Gruß
Blueberry63
So, ist eingecheckt und sollte in kürze via Update verfügbar sein.
@Bjoern,
perfekt, jetzt funktioniert's wie es soll.
Danke
Blueberry63