ich habe eben bemerkt das ich bei meinem HM-LC-Sw1PBU-FM mit toggle nur ausschalten kann. einschalten geht nicht. bei einem HM-LC-Dim1TPBU-FM geht beides.
2013-02-13 16:48:03 CUL_HM Haengelampe set_on
2013-02-13 16:48:03 CUL_HM Haengelampe deviceMsg: on (to cul2)
2013-02-13 16:48:03 CUL_HM Haengelampe on
2013-02-13 16:48:08 CUL_HM Haengelampe set_toggle
2013-02-13 16:48:08 CUL_HM Haengelampe deviceMsg: off (to cul2)
2013-02-13 16:48:08 CUL_HM Haengelampe off
2013-02-13 16:48:08 CUL_HM Haengelampe set_toggle
2013-02-13 16:48:09 CUL_HM Haengelampe deviceMsg: off (to cul2)
2013-02-13 16:48:09 CUL_HM Haengelampe off
wenn ich das eventlog richtig interpretiere wird beim zweiten toggle auch tatsächlich ein off statt einem on geschickt.
gruss
andre
Hi,
nein, geschickt wird immer nur ein toggle! Das kann long oder short sein. Was daraus gemacht wird, also ob ein oder aus oder sonstwas geschalten wird, bestimmst du in den registern des Gerätes, welches du schalten willst.
Also mal mit getConfig und reg all auslesen, was eingestellt ist. Dort ist dann der Fehler begraben.
lG
Martin
Hallo Andre und Martin
@Martin du hast recht. Das habe ich bisher nicht untersucht, aber du hast natürlich recht.
- Aber - das ist nicht sinnvoll - oder?
Toggle sollte eben toggeln. Fuer alles andere kann man einen virtuellen Button einbauen.
Beim Dimmer habe ich es schon umgebaut.
Gibt es einen sinnvollen Grund es nicht auf Toggle umzubauen wie bei Dimmern?
Gruss
Martin
ohne zu beantworten ob es sinnvoll ist oder nicht... es sollte zumindest beim dimmer und beim schalter gleich sein.
persönlich denke ich ein toggle aus fhem sollte auf jeden fall toggeln. wenn es im device noch mal die möglichkeit gibt die reaktion auf ein toggle zu konfigurieren dann wäre eventuell ein zusätzliches fhem kommando denkbar um auch das wirkliche device toggle zu senden.
welches register wäre das zum umschalten? bei einem regList sehe ich gerade nur die state machine die auf die interne taste reagiert. ich habe aber nichts gesehen womit ich sagen kann wenn ein toggle per funkt kommt macht das oder das. was habe ich übersehen ?
beim vergleich der register zwischen schalter und dimmer ist mir gerade noch aufgefallen das der Schalter kein register 1 hat und somit auch kein powerUpAction. ist das wirklich so oder fehlt die in fhem noch ?
und noch was. es gibt für die hm aktoren kein dim up oder dim down aus fhem. in der state machine aber schon. ich vermute mal das es per angelerntem taster oder fernbedienung auch gehen würde ?
gruss
andre
Hi - ähm sorry,
entweder ich bin gerade irgendwo ausgestiegen, hier fehlen ein paar beiträge oder ich steh auf der Leitung...
Was ist jetzt eigentlich das Problem?
as soll hier von wo an wen gesenet werden?
ihr redet gerade von senden eines toggles von fhem an den schalter.
Wieso sollte das etwas anderes tun als togglen? und sendet ihr jetzt kurz oder lang?
Und noch wichtiger: das habe ich bisher auch noch nicht bedacht, aber Andre hat natürlich recht:
Wenn ich direkt aus fhem einen befehl sende, welche register im aktor werden dann angewandt? Kine? Die internen? Ich hab ja keine eigenen für die Zentrale oder? ... *gerade etwas verwirrt bin*
Gibt es sowas wie versteckte register, die für die Zentrale gedacht sind?
lG
das erste ursprüngliche problem ist: wenn ich in fhem sage 'set xy toggle' geht der schalter nur aus, der dimmer hingegen wechselt zwischen an und aus wie es sein soll. beide sind original auslieferungszustand. es geht also darum was ich von fhem aus sende. nicht die konfiguration was passieren soll wenn ich den direkt mit dem taster am aktor bediene.
gruss
andre
Zitatdas erste ursprüngliche problem ist: wenn ich in fhem sage 'set xy toggle' geht der schalter nur aus, der dimmer hingegen wechselt zwischen an und aus wie es sein soll
Das kann ich genau so bestätigen.
Kann es sein das das schon immer so war und erst jetzt auffällt seit dem automatisch das attr webCmd
toggle:on:off:statusRequest hinzugfügt wird ? Dadurch wird ja bei einem klick auf das icon toggle gesendet anstatt wie vorher On oder Off
Warum eigentlich ? kann man das deaktivieren ? also das automatische generieren von webCmd
ZitatBeim Dimmer habe ich es schon umgebaut.
Gibt es einen sinnvollen Grund es nicht auf Toggle umzubauen wie bei Dimmern?
MMn nicht, wo Toggle draufsteht soll auch Toggle drin sein.
das webCmd hat nichts mit dem Kommando "toggle" zu tun, das kann es nicht gewesen sein.
Moeglich ist, dass das druecken auf die 'lampe' kein toggel ausgeloest hat sondern einfach geschaltet hat - werde ich einmal nachsehen...
Hintergrund zu toggel:
- eingebaut ist, dass ein 'tigger' an den Aktor gesendet wird. Im gegensatz zu einem 'on', da wird kein triggers sondern eben ein 'on' gesendet.
- da es bisher funktioniert hat, hatte ich es mir nicht angesehen - habe es nur fuer dimmer korrigiert.
- fakt ist, dass der 'trigger' nicht besagt, was getan werden soll, sondern dem Aktor nur mitteilt: 'tigger "x"' => bitte kuemmere dich. Bei einigen devices steht dies auf toggle, bei anderen nicht.
Man kann die Funktion im Device auch aender - dann hat es einmal funktioniert, dann wieder nicht.
Ich werde es wie beim dimmer machen
fuer freunde des "alten toggle" - das bringt mich auf die Idee ein 'press' anzubieten. dies simuliert dann einen "tastendruck am schalter" - muss ich einmal testen, sollte (hoffentlich) funktionieren
Gruss
Martin
Hallo Martin,
Zitatdas webCmd hat nichts mit dem Kommando "toggle" zu tun, das kann es nicht gewesen sein.
Indirekt schon, da vorher beim Klick auf die Glühbirne On bzw. Off gesendet wurde und nun halt toggle weil:
ZitatwebCmd
Colon separated list of commands to be shown in the room overview for a certain device. On smallscreen devices only the first value is accessible.
oder Zitat aus einem anderen Beitrag:
ZitatFalls webCmd gesetzt ist, dann wird immer der erste Eintrag von webcmd genommen.
Es gibt da ja noch einige andere Beiträge wo das automatische erzeugen von webCmd verschiedene Probleme hervorgerufen hat z.B. :
Link (http://forum.fhem.de/index.php?topic=11026.msg63472#msg63472) Zitat :
ZitatDas beim HM wg. dem eingefuegten webCmd es kaputtgeht, ist inzwischen klar.
Btw. nicht autocreate setzt das webCmd, sondern CUL_HM.
oder
Link (http://forum.fhem.de/index.php?topic=10917.msg63674#msg63674)
Da ich keine weiteren Beiträge gefunden wo näher auf das Verhalten eingegangen wird frage ich mich ob das mit der automatischen webCmd Absicht ist oder ein Bug ?
Kannst du dazu was sagen ?
ZitatIch werde es wie beim dimmer machen
Dann sollte es ja auch wieder mit der Glühbirne bzw. im Floorplan funktionieren.
Hallo Guido
habe nachgesehen, klick auf ein Icon benutzte nicht das Toggel. Es macht das, was ich jetzt sowieso vor hatte, einfach on oder off setzen, je nach status.
Toggel hatte schon immer dieses Problem ist offensichtlich einfach nicht benutzt worden.
das mit dem ersten Eintrag habe ich mittlerweile beruecksichtigt - nur dass toggel nicht toggelt.
Im naechsten update wird toggel auch toggeln
Gruss
Martin
Woran entscheidet eigentlich der Floorplan, ob er ein toggle oder on/off schickt?
Wenn ich mit der Maus über meine Icons fahre, sehe ich z.B., dass bei den Rollos (HM-LC-Bl1PBU-FM) immer ein toggle ausgelöst werden würde (egal ob on, off oder einer Prozentzahl) und bei InterTechno Funksteckdosen oder Dummies (mit "setList on off") ein on oder off (je nach aktuellem Zustand). Bei der KeyMatic schickt er immer ein lock, selbst wenn der Zustand schon so ist - auch nicht logisch... oder habe ich vergessen, etwas zu konfigurieren?
Zitat von: justme1968 schrieb am Mi, 13 Februar 2013 20:23beim vergleich der register zwischen schalter und dimmer ist mir gerade noch aufgefallen das der Schalter kein register 1 hat und somit auch kein powerUpAction. ist das wirklich so oder fehlt die in fhem noch ?
und noch was. es gibt für die hm aktoren kein dim up oder dim down aus fhem. in der state machine aber schon. ich vermute mal das es per angelerntem taster oder fernbedienung auch gehen würde ?
weiss noch jemand etwas zu den beiden anderen fragen ?
gruss
andre
switches haben keine 'list 1'.
dimmen geht beim dimmer.
man kann mit einer Rampe hoch oder runter fahren, die rampenzeit programmieren,...
Aber was du willst ist das dimmen per button interaktiv - richtig? Das funktioniert so:
wird es bei einem langen tastendruck gemacht.
Langer Tastendruck bedeutet praktisch, dass remote alle 0.4sec einen trigger sendet und der dimmer immer eine Stufe heller/dunkler wird. so lange bis kein trigger mehr kommt.
Macht ein dim-up/down sinn? sollte man so ein Kommando bereitstellen?
Gruss,
Martin
hallo martin,
danke für den denkanstoß. ich denke dann braucht es kein dimup und dimdown.
gruss
andre
ps: eigentlich drauf gekommen bin ich weil ich mir den led dimmer bestellt habe. der fs20 vorgänger hat nämlich das problem das dim6% nicht die kleinste helligkeit ist sondern ich noch mal ein dim down hinterher schicken muss. bei hm ist das aber eh nicht nötig. ich kann ja mit pct direkt in 1% stufen dimmen.
Hi,
bei HM schaltern ist dies aehnlich - oder man kann es so manchen.
Jeden button - auch die Eingebauten - kann man programmienren.
Beispiel
anschalt-Button (bei getrennem an-ausschalter
short press
- shOnLevel 60% => bei kurzem Druck auf diesen button werden 60% eingestellt
- shRampOnTime => geschwindigkeit des einschaltens
mit long-press kann man dann weiter hochdimmen
- lgOnLevel 100% => bei kurzem Druck auf diesen button werden 60% eingestellt
ausschalt-Button (bei getrennem an-ausschalter
short press
- shOffevel 10% => bei kurzem Druck auf diesen button werden 10% eingestellt
- shRampOffTime => geschwindigkeit des runterdimmens
ausserdem:
DimMinLvl
DimMaxLvl
alles malansehen.
ich habe bei meinem dimmer auch einen default min level eingestellt. Aus verschiedenen gründen
a) das niemand beim runterdimmen auf 5% stehenbleibt,weil er glaubt es sei ausgeschaltet und der dimmer ewig laeuft
b) manche lampen mögen sehr geringe level nicht, fangen an zu flackern
c) devault-on in einigen bereichen soll nicht 100% sein, das ist die Ausnahmen
hier hat man Einstellmöglichkeiten ohne ende - und das alles je gepeertem Button
Nicht zu vergessen die virtuellen Channels der dimmer - die muss ich noch sichtbar machen...
Gruss
Martin
hallo martin,
oh ja. sehr viel zum probieren biss es so geht wie man es sich vorstellt :)
mit den virtuellen channels am led dimmer habe ich gestern gespielt. das geht jetzt schon mit fhem bordmitteln wunderbar.
gruss
andre
ein problem mit den virutellen channesl habe ich eben doch noch gefunden.
wenn ich alle drei virtuelle channes definiert habe im device per set etwas mache bleibt im device selber der state immer auf set_... stehen.
also ein set LED on schlatet das licht an aber bei der LED bleibt der state auf set_on stehen. nur der channel 1 wird auf on aktualisiert.
gruss
andre
du hast also ein device und einen channel 1 (evtl noch mehr channels..., egal)
nun schaltest du nicht den channel 01 'on' sondern das device.
Per default werden "channel-kommandos" (z.B. on,off) auf den ersten channel angewendet. Somit kann der User die Definition des ersten channels sparen. Dies macht m.E. sinn bei 1-channel devices.
Um das Problem zu loesen kann , wenn ein channel 01 eingerichtet ist
a) der User kein ON/OFF auf devices ausfuehren
b) fhem channel-kommandos fuer devices sperren
c) status eines channels nicht im device angezeigt werden
a) kannst du schon jetzt machen
b) werde ich mir ueberlegen - koennte aber bei manchen Usern zu problemen fuehren.
c) werde ich mir auch ueberlegen
Gruss
Martin
das ich statt das on/off ans device zu senden den channel nehmen sollte ist mir klar. es hat zum teil historische gründe. beim automatischen anlegen kommt halt nur das device. das mit den virtuellen channels habe ich erst später erfahren und es ist ja ein wenig ein sonderfall das die channel virutell sind und das device eigentlich den virtuellen channel 1 schaltet. die virtuellen channel 2 und 3 dann noch zusätzlich verknüpft werden.
auch ist es von der handhabung nicht sehr praktisch statt dem device den channel1 im raum zu haben. das wäre vielleicht eine lösung wenn es zwischen device und channel in beide richtungen ein link gäbe. die liste der channe ist im device ja schon da aber nicht anklickbar.
die alternative alles beides zu haben ist dann wieder unübersichtlich.
es gibt noch lösung d): channel 1 nicht anlegen sondern nur das device und channel 2 und 3. dann funktioniert es.
die virtuellen channels sind aber in noch einer hinsicht ein sonderfall. der endgueltige device status ist ja die kombination aus allen channels. und eigentlich wäre es ja schön den auch in fhem sehen zu können. d.h. die set werden nur auf den channel zugelassen sobald der erste virtuelle channel definiert wird und der channel status wird auch nur im channel angezeigt. im device wird der kombinierte status angezeigt. wenn das mit der kombination geht könnte man sogar das set auf das device zulassen und dadurch das es auf den ersten channel geht stimmt das kombinierte ergebniss ja wieder. ich hoffe das klingt nicht zu verworren.
gruss
andre
Für mich klingt das ganz logisch. :-)
Ich hab momentan einfach alle devices hidden gesetzt, frag mich gerade welche Informationen mir jetzt verloren gheen, die du eben nicht verpassen willst *grübel*
Okay, batterie, bei solchen Geräten, die das haben, aber das fang ich ja ab, was gibts sonst noch alles,was uns nur das device sagt?
lG
Martin
zum beispiel die helligkeit :)
ich kann ja mit den virtuellen channels das device bzw den channel 1 z.b. nachts autmatisch auf 1% setzen und per bewegunsgmelder channel2 auf 50% für 5 minuten.
die 50% für 5 minuten sehe ich in fhem dann nicht.
gruss
andre
Ah, okay, hab keinen Dimmer, daher ist mir das nicht klar gewesen.
Richtig wäre aber, um das Konzept korrekt fortzuführen:
du setzt kanal 1 auf x
kanal 2 auf y
und dies wird dir in fhem jeweils beim passenden kanal angezeigt.
Die Anzeige im Device für die Helligkeit eines Kanals ist falsch. Die sollte eben nicht da sein! :-)
Ausnahme: es gibt nur einen Kanal, dann existiert dieser für den Nutzer nicht und die Anzeige erfolgt (wie die eingabe) beim device.
Sobald der Kanal (auch wenn er der einzige ist) angelegt ist, sollte (muss) jede Anzeige die nur den Kanal betrifft auch dort angegeben und angezeigt werden. Also Helligkeit von Kanal 1 hat beim Device nichts zu suchen.
Was dort reinfallen würde ist z.B. die Batterie, denn diese gilt für das Gerät, egal welcher Kanal.
Denke so sollte es sein und wenn es irgendwo nicht so ist wird Martin sicherlich schnell nachbessern.:-)
lG
Martin
das ist nicht ganz richtig. die gesamthelligkeit also das ergebnis der verknüpfung aller virtuellen kanäle gehört ins device. und ich möchte ja dann auch das device also den gesamtsatus im floorplan anzeigen. nicht die drei kanäle nebeneinander und dann im kopf auszurechnen wie der zustand gerade ist.
die option in der device detail ansicht da wo die kanäle angezeigt werden direkt ein status und webCmds zu haben wie in der raum übersicht wäre sicher auch nett...
gruss
andre
@Martin: hier geht es speziell im die virtual channels der dimmer. Das hat nichts mit fhem-virtual zu tun, gibt es auch nur bei dimmern bis jetzt.
HM-realisierung der channels ist:
3 Channels je 'Lampe' sind standart. Einen bezeichne ich als 'physikalischen Channel' und 2 als virtuelle. Das Ergebnis ist nicht unbedingt eine Addition sondern kann beliebig verknuepft werden: add,sub,mul,xor.....
geaendert ist, dass der status bei "on/off" immer zum Channel 01 geht, falls dieser vorhanden ist.
eine Verlinkung kann man ueberlegen - erst einmal muss ich das Verhalten verstehen. Es handelt sich hier eigentlich nur um den Fall dimmer mit HM-vurtuellen Channels - korrekt?
Das mit dem Anklicken der channels bekomme ich nicht so einfach hin. HM mit den Devices ist nicht FHEM standard. Da mach ich nicht viele Freunde, wenn ich am web-interface schraube.
Ich benutze rooms um entities zu gruppieren, nicht nur nach raeumen sondern auch nach funktionen. Romms ist hervorragend geeignet im web-groups zu verwalten.
Zitates gibt noch lösung d): channel 1 nicht anlegen sondern nur das device und channel 2 und 3. dann funktioniert es.[\quote]
das ist der default fuer 1-channel-dimmer
Status der Channel:
verstanden habe ich deine erkaerung und den Hintergrund.
die Logik in FHEM nachzubauen will ich vermeiden - und hoffen dass dies HM macht.
hast du ein Beispiel aufgebaut und kannst es schicken? werde es selbst auch einmal testen... vielleicht mit einem einfachen 'add'.
Zitatdas ist nicht ganz richtig. die gesamthelligkeit also das ergebnis der verknüpfung aller virtuellen kanäle gehört ins device[\quote]
auch nicht ganz richtig. Das Konzept soll durchgaengig sein und sich logisch ableiten lassen. Also muessen wir auch 2-channel dimmer mit 2phys und 4 virt channels koennen, plus eine device-entity.
=> die resultierende Helligkeit sollte immer im phy-channel 'state' stehen.
=> das Device ist - falls channel'1' nicht angelegt ist - stellvertreter fuer diesen channel 1. Das ist so das will ich nicht grundlos abschaffen
=> man muss sehen koennen, welchen Zustand jeder einzelne Channel hat, virt oder phys, egal
Ich werden etwas experimientieren.Wie es aussieht werde ich einen 'virtState' einfuehren der den Zustand virtueller Dimmer-cahnnels anzeigt.
Gruss
Martin
hallo martin,
vor der langen antwort ganz kurz der hinweis auf das neue devStateIcon feature.
damit kann man super flexibel dynamisch icons erzeugen die nicht mehr nur vom state abhängen. schau dir mal an wie ich es im HUEDevice mit einem 'get devStateIcon gelößt habe. ähnlich koennte man die einzelnen channel verknüpfen um das icon zum device zu erzeugen.
gruss
andre
hallo nochmal,
- ja. ich habe es gerade von dimmer mit den virtual channels. bei mir ist es die led version aber ich glaube das ist egal.
- das mit dem gruppieren ist mir klar. aber es ist nicht die elegante lösung :) erst recht weil am ende das device und die channel mehrfach und in unterschiedlichen räumen auftauchen.
- zum logik nachbauen: ich habe auf die schnelle nicht gesehen das man den summenzustand abfragen kann. aber das rauszufinden bist du besser geeignet.
ich hatte ein beispiel musste den bewegungsmelder aber kurzfristig woanders verwenden. der neue ist aber schon bestellt.
- das das konzept nicht nur spziell für den dimmer mit den drei virtuellen kanälen greifen soll ist klar. das war nur auf die schnelle mein beispiel. wobei ich zwei physikalische kanäle eher als zwei devices abbilden würde weil die lampen die daran hängen ja räumlich nicht unbedingt nebeneinander sein müßen und es im floorlpan ja auch verwendet werden soll. das gilt z.b. aber auch für den 4fach hutschinen aktor. wobei das problem hier entschärft ist weil es keine vermischnug der kanäle gibt. die sind halt alle real und unabhängig. da brauche ich das device an sich nicht sichtbar zu haben.
- eventuell ist auch hier das neue devStateIcon feature nützlich. damit könnte man auch zwei birnen nebeneinander darstellen.
- ja. die stati als reading zu haben ist sicher der richtige erste schritt. das kombinieren an sich ist dann glaube ich gar nicht so aufwändig. und das darstellen des ergebnisses geht per devStateIcon inzwischen mit bordmitteln.
gruss
andre
Hallo Andre,
das devStateIcon muss ich mir ansehen. Wo ist dein Beispiel? In wiki?
das Auslesen des Phys Zustands werde ich probieren, aber keine Garantie... erst mal probieren.
das errechnen ist eine Option - sicher auch machbar. Ich habe nur immer ein Problem wenn ich die Daten nicht habe. falls die config nicht gelesen wurde oder alt ist... alles nicht schoen - zu viele Unsicherheiten. Also nur, wenn nicht anders moeglich.
devStatIcon benutze ich auch. denke darueber nach auch hier einen default in HM einzutragen, wie bei webCmd. Das sollte es vorallem Anfaengern erleichtern, reinzukommen. es ist sonst schon seltsam wenn mein Rollo als Lampe angezeigt wird.
Wie gesagt, das kombinieren ist nicht mein Problem. Die Gefahr der schlechten/alten Daten ist es, die mich stoert.
Gruss
Martin
hallo martin,
ein beispiel ist im 'get devStateIcon' in 31_HUEDevice.pl und der default initialisierung vom attribut devStateIcon. ein anderes hier Link (http://forum.fhem.de/index.php?topic=11255.msg66144#msg66144)
das mit dem fehlenden daten für das berechnen sehe ich nicht so kritisch. in dem fall wären ja auch die stati und icons der channel falsch. und damit können wir auch leben. und zumindest intern wäre alles konsistent.
gruss
andre
wie waere es mit einem dynamischen icon das den Status von der 16 LED Anzeige darstellt?
lass mich mal probieren, ob wir den Zustand sauber geregelt bekommen, das waere das Beste.
Aber igendeine Zusammenfassung werden ich sicher machen, das ist auch klar.
Das mit den Icons ist elegant, muss ich mir einmal durchdenken, wo/wie dies sinnvoll ist.
Zwischenstand: Der physikalische Wert wird ausgegeben. Ich muss also nicht rechnen....
Muss noch an der Impelmentierung arbeiten...
klasse!
gruss
andre
so ist drin.
Es gibt jetzt einen virtLevel. Das ist der Beitrag dieses Kanals.
Der State ist bei allen gleich - immer der physikalisch Wert.
Kommentare?
Gruss
Martin
hab noch einmal nachbessern muessen. Der Phys Level kommt nur bei der StatusInfo, nicht in der ACK_STATUS.
Muss jetzt nicht jeder verstehen..., ich muss nur etwas mehr aufpassen....
Der Phys-Level kommt dann evtl nicht, wenn der dimmer nicht an einer Zentrale angelernt ist... Schon lange nicht mehr probiert.
Ist aber eh ein sonderfall...
Gruss
Martin