Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

[Robert]

Scherzkecks

Selber ;-P Ne, schon verstanden - ich meinte halt "nur verschieben" oder "nur Haken dran", aber halt nicht aus zwei Threads einen (evtl. missverständlichen) machen. Insbesondere da der zweite bewusst "kurz" und problemorientiert war. Aber so passt es jetzt auch, zumal wir hier ja vielleicht bald nen Haken dran machen können.

Hallo Robert,

danke, sieht gut aus.

def en5001(value):
   return [0, int(int(value) * 255[COLOR=Red].0[/COLOR] / 100) & 0xff]

sollte auch noch geändert werden.

Möchtest Du es einchecken?

Ja, wollte ich auch noch vorschlagen. Zudem: Kann de5001 nicht ein float zurückgeben und bei en5001 der cast auf int entfallen? Intern gibt es doch eh float-Verarbeitung! Dadurch werden die Fehler noch geringer.

Ich würde es dann gerne einchecken - muss nur noch schauen wie ich das mit dem GIT hinbekomme.

Ich habe seit einiger Zeit ein ähnliches Verhalten beim Dimmen meiner über ein KNX-DALI-GW angebundenen Downlights:
Licht ist aus
Ich dimme per Taster auf z.B. 40%
Kurz danach (wenige Sekunden) wird das Licht 'von Geisterhand' auf 100% gesetzt

Ohne Prophet zu sein: schätze das ist das gleiche Problem wie bei mir. Du hast wahrscheinlich ein Item mit send_item für den Helligkeitswert, was auch auf die Rückmeldung hört (watch_item). sh.py will jetzt wenn die Rückmeldung (watch_item) kommt das für sh.py scheinbar nicht aktualisierte send_item aktualisieren und schreibt dort den Wert hin. Aufgrund der Rechenungenaugikeit ist das aber ein anderer Wert als der zurückgemeldete. Hier beginnt dann ein Spiel aus Update/Rückmeldung.

Kurz, auch wahrscheinlich für Niko:

[Item]
send_item = x
watch_item = y

Wenn y empfangen wird wird zwangsweise x geupdated und - falls bisher noch nicht auf den Bus gesendet oder sowieso wenn force_updates = true - auch wieder gesendet. Das ist richtig so, sonst hätte das Item keinen konsistenten Wert.

Die Abfrage auf "knx" ist also korrekterweise entfernt worden und überdeckte nur einen "logischen Fehler" in der Item-Definition (siehe die kurze Beschreibung meines Leuchten-Problems hier im Thread)

Das Hochschaukeln ist zwar ähnlich gelagert aber keine direkte Folge dessen. Hier ist es völlig ok, Rückmeldung und Setz-GA gemeinsam zu haben, sofern bei geänderter Status-GA (z.B. durch hoch-runter bei der Jalousie) auch gefahrlos die Absolutposition neu geschrieben werden darf (ist dann ohne Rundungsfehler harmlos).

Grüße
Robert

[2ndsky]

Klar, wenn ich den Status 100% empfange und sende dann wieder 100% ist das zunächst kein Problem. Dennoch finde ich es unschön, wenn der Status über KNX empfangen und dann wieder auf den KNX gesendet wird. Außerdem erzeugt das zusätzliche Buslast, die nicht sein muss. Das mag im normalen EFH noch egal sein, bei größeren Objekten könnte das aber schnell zum Problem werden.

Wenn du von einem logischen Fehler bei der Item Konfiguration sprichst, wie sollte diese dann aussehen bei Wert-GA X und Status-GA Y?

EDIT: in deinem Fall war es ja das Problem, dass die Dauerbeleuchtung mit dem Status der Lampe verknüpft war. Ich will aber den Status der Lampe mit dem Schalten der Lampe (nicht der Dauerbeleuchtung) haben.

[callidomus]

Hi Niko,

ich habe Dein Setup noch mal durchdacht.
Ich denke man muss leider das senden über zwei unterschiedliche Attribute regeln.

knx_??? = A # sendet an A wenn sich der Wert nicht über KNX ändert (SchaltGA)
knx_??? = B # sendet an B wenn sich der Wert ändert (StatusGA)

Verständlich was ich meine?

Bis bald

Marcus

[callidomus]

Ja, wollte ich auch noch vorschlagen. Zudem: Kann de5001 nicht ein float zurückgeben und bei en5001 der cast auf int entfallen? Intern gibt es doch eh float-Verarbeitung! Dadurch werden die Fehler noch geringer.

Ich würde es dann gerne einchecken - muss nur noch schauen wie ich das mit dem GIT hinbekomme.

Ein KNX DPT 5.001 liefert kein Float, daher denke ich sollte das de5001 auch kein Float liefern.
Das cast auf int bei dem en5001 könnte prinzipiell weg, ich habe es für den Fall eingebaut das ein Benutzer ein Bool oder String als type angiebt, selbst damit würde es funktionieren. Es stört meiner Meinung nach nicht und darf daher bleiben.

Auf
https://github.com/mknx/smarthome/bl.../dev/README.md
habe ich noch einen Punkt "Push changes" eingefügt.

Bis bald

Marcus

[umatz]

Bin gerade unterwegs, kann heute Abend Logs und Config nachliefern.

So, hier die Details:
SmartHome.py Version: 0.9-Beta-17-g5a480bb
Item Definition:

[eg]
    [[wohnzimmer]]
        name = Wohnzimmer
        sv_page = room
        sv_img = scene_livingroom.png
        [[[deckenspots]]]
            name=Deckenspots
            type=bool
            visu=yes
            sv_widget = "{{ device.dimmer('item', 'item.name', 'item', 'item.dimmwert', '0', '100') }}"
            knx_dpt=1
            knx_send=1/0/2
            knx_init=1/0/22
            [[[[dimmwert]]]]
                type=num
                visu=yes
                knx_dpt=5001
                knx_send=1/0/39
                knx_init=1/0/29

Und kommentierter Logauszug des problematischen Verhaltens:

2013-06-19 21:48:52,533 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 9 -- __init__.py:parse_telegram:180
# Beginn Dimmen am Taster
2013-06-19 21:48:53,688 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 0 -- __init__.py:parse_telegram:180
# Loslassen Tasterwippe
2013-06-19 21:48:56,105 SmartHome.py INFO     knx: 1.1.5 set 1/0/29 to 25 -- __init__.py:parse_telegram:185
# DALI-GW (1.1.5) meldet auf Dimmwert-Status-GA 25 zurück
2013-06-19 21:48:56,105 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots.dimmwert = 25 via KNX 1.1.5 -- item.py:_update:219
# SH aktualisiert item mit Statuswert
2013-06-19 21:48:56,106 SmartHome.py INFO     knx: 15.15.2 set 1/0/39 to 3f -- __init__.py:parse_telegram:180
# eibd (15.15.2) sendet 3f (und nicht 25!) auf die Dimmwert-Setz-GA (1/0/39)  (vermutlich getriggert durch SH?)
2013-06-19 21:48:56,147 SmartHome.py INFO     knx: 1.1.5 set 1/0/22 to True -- __init__.py:parse_telegram:185
# DALI-GW setzt den Schalt-Status (1/0/22) auf True und ursprünglich nur sanft gedimmtes Licht geht volle Kanne an
2013-06-19 21:48:56,147 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots = True via KNX 1.1.5 -- item.py:_update:219
# SH aktualisiert item mit Statuswert True 
2013-06-19 21:48:56,148 SmartHome.py INFO     knx: 15.15.2 set 1/0/2 to 1 -- __init__.py:parse_telegram:180
# eibd sendet True auf Schalt-GA (vermutlich getriggert durch SH?)

2013-06-19 21:48:59,619 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 1 -- __init__.py:parse_telegram:180
# Ab hier beginnt mein Korrekturdimmen am Taster um Helligkeit wieder zu reduzieren
2013-06-19 21:49:03,898 SmartHome.py INFO     knx: 1.1.9 set 1/0/9 to 0 -- __init__.py:parse_telegram:180
2013-06-19 21:49:11,232 SmartHome.py INFO     knx: 1.1.5 set 1/0/29 to 29 -- __init__.py:parse_telegram:185
2013-06-19 21:49:11,233 SmartHome.py DEBUG    eg.wohnzimmer.deckenspots.dimmwert = 29 via KNX 1.1.5 -- item.py:_update:219
2013-06-19 21:49:11,234 SmartHome.py INFO     knx: 15.15.2 set 1/0/39 to 49 -- __init__.py:parse_telegram:180
# Auch hier wird wieder ein anderer Wert als ursprünglich reinkam auf den Bus gesendet (49 statt 29)!

Dieses Verhalten habe ich seit einigen Wochen, vorher lief das Dimmen problemlos.

Ich denke man muss leider das senden über zwei unterschiedliche Attribute regeln.

knx_??? = A # sendet an A wenn sich der Wert nicht über KNX ändert (SchaltGA)
knx_??? = B # sendet an B wenn sich der Wert ändert (StatusGA)

Das habe ich noch nicht verstanden. Mir erscheint meine Item-Definition wie oben angegeben logisch und sauber.
Wäre mein Problem behoben, wenn ich nur die in diesem Thread enthaltenen Patches (also die Korrektur der Umwandlung von DPT5.001) anwende ohne meine Konfig zu ändern?

Greetinx,
Udo

[2ndsky]

Bug: Umwandlung von/nach DPT 5.001 nicht konsistent!

Hallo Udo,

die Schleife und damit dein Hauptproblem wäre behoben, ja.

@Marcus: wenn ihr das verhalten so haben möchtet, das über den Bus empfangene Werte auch wieder auf den Bus gesendet werden, dann brauchen wir separate Attribute.

Was mir allerdings nicht klar ist, wozu ihr das braucht. Wenn ich am Russound die Lautstärke per App auf 20 setze, sh.py den Wert vom Russound empfängt, dann braucht sh.py die Lautstärke ja nicht nochmal auf 20 setzen... die ist ja schon 20. Bei KNX sehe ich das genauso. Wozu also dieses Verhalten?

[Robert]

@Marcus: wenn ihr das verhalten so haben möchtet, das über den Bus empfangene Werte auch wieder auf den Bus gesendet werden, dann brauchen wir separate Attribute.

Was mir allerdings nicht klar ist, wozu ihr das braucht. Wenn ich am Russound die Lautstärke per App auf 20 setze, sh.py den Wert vom Russound empfängt, dann braucht sh.py die Lautstärke ja nicht nochmal auf 20 setzen... die ist ja schon 20. Bei KNX sehe ich das genauso. Wozu also dieses Verhalten?

Hi Niko,

ich kann mal versuchen meine Sicht zu erklären:

Ein Item - ein Wert - egal woher dieser kommt (KNX, Onewire, Plugin x, ...)

Nur so ist es ja auch möglich, z.B. ein Plugin (z.B. Onewire) das Plugin updaten zu lassen und es dann "automatisch" über das KNX-send_item raussenden zu lassen. Wie soll jetzt sh.py unterscheiden, ob das send_item bei einem Item-Update aktualisiert werden soll oder nicht? Die Abfrage auf "knx" ist zu KNX-zentriert und führt zwangsweise ins Nirvana wenn man sh.py als Technologie-agnostische Logikengine positionieren will. Möglich wäre also nur, eine Spiegelung generell zu verhindern, also nie auf das caller-Medium zurückzuschreiben. Aber auch das wäre ggfl. für Umrechnungen etc fatal.

Die Zusammenführung zweier GAs (Vorgabe und Status) gibt irgendwo ja auch den Sinn eben dieser Trennung auf. Dann könnte man auch vielfach bereits im KNX eine GA für beides verwenden - mit allen Nachteilen.

Eine richtig gute Lösung weiß ich auch nicht - allerdings denke ich, dass oben geschriebener Grundsatz halt immer zwangsweise gelten sollte und eben auch von sh.py sichergestellt werden sollte (notfalls eben per GA-write).

Evtl. könnte man ein "lazy-update" Attribut einführen (default = False!), was das Schreiben für gleiche Technologien (Plugins) verhindert. Allerdings wird dann auch z.B. von Visu auf Visu verhindert... Da bohrt man sich schnell logische Löcher...

Grüße
Robert

[2ndsky]

Nur so ist es ja auch möglich, z.B. ein Plugin (z.B. Onewire) das Plugin updaten zu lassen und es dann "automatisch" über das KNX-send_item raussenden zu lassen. Wie soll jetzt sh.py unterscheiden, ob das send_item bei einem Item-Update aktualisiert werden soll oder nicht?

Da kann ich dir jetzt nicht folgen. Wenn man die Quelle der Änderung prüft (caller != KNX), dann kann ich über 1Wire geänderte Werte doch auf den KNX schreiben, weil der Aufrufer ist dann ja nicht KNX.

Die Abfrage auf "knx" ist zu KNX-zentriert und führt zwangsweise ins Nirvana wenn man sh.py als Technologie-agnostische Logikengine positionieren will.

Da kann ich dir nicht folgen. Kannst du mir das bitte im Detail erklären, warum das zu Problemen führt, am besten mit Beispiel. Wenn ich verstehe, warum ihr das unbedingt braucht, vielleicht kann ich mich dann auch besser an einer Lösung des Problems beteiligen.

Möglich wäre also nur, eine Spiegelung generell zu verhindern, also nie auf das caller-Medium zurückzuschreiben. Aber auch das wäre ggfl. für Umrechnungen etc fatal.

Aber das würde caller != KNX doch machen, eine Spiegelung auf das Empfangsmedium verhindern, oder? Wenn nein, bitte Erklärung. Und warum wäre das für Umrechnungen fatal?

Die Zusammenführung zweier GAs (Vorgabe und Status) gibt irgendwo ja auch den Sinn eben dieser Trennung auf. Dann könnte man auch vielfach bereits im KNX eine GA für beides verwenden - mit allen Nachteilen.

Okay, dann soll ich quasi ein Item für Status und eins für das Senden definieren, richtig? Dann brauchen wir diese Trennung aber auch in der smartVISU. Wie soll ich sonst in der Visu den Status meiner Lampe getrennt von einer Wertänderung in der Visu machen?

Mit der bisherigen Abfrage caller != KNX hat das alles bestens und einwandfrei funktioniert.

Eine richtig gute Lösung weiß ich auch nicht - allerdings denke ich, dass oben geschriebener Grundsatz halt immer zwangsweise gelten sollte und eben auch von sh.py sichergestellt werden sollte (notfalls eben per GA-write).

Evtl. könnte man ein "lazy-update" Attribut einführen (default = False!), was das Schreiben für gleiche Technologien (Plugins) verhindert. Allerdings wird dann auch z.B. von Visu auf Visu verhindert... Da bohrt man sich schnell logische Löcher...

Wie gesagt, ich versteh nicht warum ihr das braucht... ich brauch es nicht und ich finde auch keinen Anwendungsfall. Bisher hat es bei mir reibungslos funktioniert, mit der Änderung habe ich Probleme bei meiner Installation. Wenn wir keine gute Lösung dafür finden, werde ich bei mir nach jedem Update das Statement einfach wieder einbauen und gut ist. Für mich zwar keine optimale Lösung (da ich denn Sinn nicht sehe), aber dann ist es halt so.

[callidomus]

Hi Niko,

Wie gesagt, ich versteh nicht warum ihr das braucht... ich brauch es nicht und ich finde auch keinen Anwendungsfall. Bisher hat es bei mir reibungslos funktioniert, mit der Änderung habe ich Probleme bei meiner Installation. Wenn wir keine gute Lösung dafür finden, werde ich bei mir nach jedem Update das Statement einfach wieder einbauen und gut ist. Für mich zwar keine optimale Lösung (da ich denn Sinn nicht sehe), aber dann ist es halt so.

man braucht das wenn man SH.py als KNX-Aktor betrachtet und den Zustand zuätzlich z.B. die Visu ändert.
Wir werden aber eine Lösung finden die Deinen und den anderen gerecht wird.

Bis bald

Marcus

[2ndsky]

man braucht das wenn man SH.py als KNX-Aktor betrachtet und den Zustand zuätzlich z.B. die Visu ändert.

Also wenn ich quasi über KNX das Item setzen möchte und im KNX erfahren möchte, ob der Wert tatsächlich gesetzt wurde? Am Beispiel Russound, es gibt eine GA zum Einschalten einer Zone und eine GA die mir den Status der Zone mitteilt. Verstanden.

Allerdings ist der Anwendungsfall so nicht abzubilden. Denn das einzige was ich durch die Antwort weiß, dass sh.py den Wert empfangen hat und somit ob sh.py läuft. Ob sh.py es tatsächlich geschafft hat, die Zone zu aktivieren oder ob es Fehler bei der Kommunikation mit dem Russound gab weiß ich dann ja wieder nicht.

Um das dann tatsächlich abbilden zu können bräuchte man schon etwas das ein klein wenig mächtiger ist. Damit sh.py den Status eines Items nur dann ändert, wenn andere angebundene Plugins diese Änderung auch durchsetzen konnten.

[marsellus]

Hi,

ich muss Niko an dieser Stelle zustimmen und werde es bis auf Weiteres auch so machen müssen, dass ich nach einem Update die Zeile "if caller != 'KNX'" wieder reinnehme.

Das Argument von Marcus, dass sh sich wie ein Aktor verhalten soll kann ich nachvollziehen...ist aber technisch so nicht umgesetzt. Ein Aktor übermittelt seinen tatsächlichen Schaltzustand - nachdem er einen "Änderungswunsch" erhalten hat. Sh macht einfach einen "Autoreply" ohne dass das den tatsächlichen Schaltzustand des "Sh-Aktors" unbedingt widerspiegeln muss.
Ein regulärer Aktor erlaubt es den Schaltzustand und Status zu trennen. Sh mischt diese wieder zusammen über knx_listen und knx_send, was ja durchaus sinnvoll ist und ich auch für die SmartVisu benötige. Die Items in sh sind für mich eher die Schnittstelle(ndefinition) zu den technischen Komponenten, die möglichst wenig Eigenleben haben sollte.

Für mich ist sh in erster Linie ein Integrationssystem zwischen den Welten, wo ein Forwarden von Informationen zwischen den Welten gewollt/erwünscht ist und über die Items einfach konfiguriert werden kann. Soll sh ein aktives Verhalten á la KNX-Aktor haben, würde ich das gern explizit über Logiken machen wollen.

Einen Anwendungsfall, wo ich das benötige, habe ich mit meiner Tag-Nach-Umschaltung die sowohl über KNX-Taster, die Visu und zeitgesteuert erfolgen kann. Dafür habe ich mir jetzt aber genau EINE Logik geschrieben die Änderungen für ein Item auf knx_listen via knx_send (auf eine andere GA) weiterleitet. Bei Bedarf hänge ich an das watch_item der Logik einfach weitere Items an. Die Logik liest dann für das betreffende Item einfach die knx_send-GA aus und schickt den Wert weiter.

Hier kann aufgehört werden zu lesen, ich beschreibe einfach mal kurz warum "if caller != 'KNX'" bei mir nicht funktioniert:
Ich habe eine Tag-Nacht-Umschaltung bei der Nachts die Beleuchtung in Bädern und Dielen reduziert wird. In sh habe ich ein Item das die GA des Schaltzustand des Dimmaktors (Ein/Aus) mit der GA für das Schalten des Dimmers verbindet. Brauche ich so für die SmartVisu und ist ja eigentlich auch so gewollt.
Das ist dann der Ablauf:
-> PM im Bad sendet Nachts 30% auf den Bus an die entsprechende Dimm-GA
-> Dimmer geht auf 30%
-> Dimmer sendet auf die Schaltzustand-GA (die ich auch in sh verwende) ein "EIN"
-> Dimmer sendet auf eine andere Status-GA seinen Dimmwert
-> Sh registriert die Änderung auf der Schaltzustand-GA (="EIN")
-> Sh macht ein "Autoreply" mit Wert "EIN" an die Schalt-GA des Dimmers
-> Dimmer schaltet die Beleuchtung daraufhin auf 100%

Das Autoreply des "EIN" auf die Schalt-GA des Dimmers ist an dieser Stelle eben nicht das gewünschte/erwartete Verhalten.


/Marcel

[greentux]

Auch wenn der Thread komplett aus dem Titel Ruder gelaufen, ich hoffe, es gehört hier her:

Ich habe derzeit folgende Werte:

sensor.bad.temp = 23.5
sensor.bad.hum = 52.94117647058823

Aus folgender Config:

      [[bad]]
        [[[temp]]]
            visu_acl = rw
            type = num
            knx_dpt = 9
            knx_listen = 3/2/71
            sqlite = yes
        [[[hum]]]
            visu_acl = rw
            type = num
            knx_dpt = 5.001
            knx_listen = 3/2/72
            sqlite = yes

Der hum Wert hat mir definitiv zu viele Nachkommastellen für DPT5.001
Gehört das zum hier besprochenen Problem?

Im Log steht zu der Zeit:

2013-12-09 22:40:47,959 DEBUG    Main         knx: 0.0.0 set 3/2/72 to 52.15686274509804 -- __init__.py:parse_telegram:190
2013-12-09 22:40:47,964 DEBUG    Main         Item sensor.bad.hum = 52.15686274509804 via KNX 0.0.0 3/2/72 -- item.py:__update:363

Über den KNX läuft zu der Zeit:

2013-12-09 22:37:53.133,A_GroupValue_Write,0.0.0,3/2/72,85,52.2,DPT_Scaling,5.001,0,low,7,T_DATA_XXX_REQ,0

[Robert]

Neee, das Originalproblem war die Inkonsistenz der Umwandlungen. Wenn ein DPT5 in den Wert gewandelt wurde, und dieser dann wieder in DPT5 gewandelt wurde kam ein anderer Wert raus. Das wiederholte sich dann beliebig oft. Zusammen mit dem Damals vorhandenen Echo auf dem KNX-Bus gabs dann Gemüse. Das ist alles behoben.

Bei dir sehe ich gar keinen Fehler? Vielleicht solltest du zumindest deine Erwartung beschreiben? Einzig falls die Werte zusammengehören sieht die Rundung etwas seltsam aus. Ansonsten ist doch alles ok?

[JuMi2006]

Ich denke Du willst sowas:
https://github.com/mknx/smarthome/co...0a2fd581d11219

Ich hatte das damals beim DPT9 irgendwo hier gemeldet.

[greentux]

DPT5.001 ist definiert mit einer Auflösung von 0,01
Das sieht mir auf dem Bus auch noch so aus. Im sh.py halt dann leider nicht mehr.
Auch bei den Temperaturen (DPT9) habe ich manchmal mehr Stellen, als die defnierte Resolution von 0,01

Warum braucht man denn da dann ein Round?
Wo kommen die "Mehrstellen" denn her?

Gruß