HomeKit Brücke für KNX

[brutella]

wwfr Sorry, deine Frage hab ich übersehen. Ich pack dieses Feature mal auf Github → https://github.com/brutella/hkknx-public/issues/309

[wwfr]

Noch eine weitere Frage bzgl. der Temperatursteuerung: Ist der Kelvin-Wert links und rechts festeingestellt bzw. von HomeKit vorgegeben?

IMG_9359.png
IMG_9360.png
Ich möchte Lampen ansteuern die einen sehr hohen CCT-Bereich abdecken können (von 1800-16000K)...

brutella Würde mich um kurze Rückmeldung freuen


Es fehlt in hkknx eine Funktion, die die min. und max. Kelvin der Leuchte definiert, damit der Temperaturpicker in der Home App die richtigen Werte/das volle Spektrum der Lampe abdecket. Thinka hat das implementiert: hier

Screenshot 2024-04-22 at 21.08.47.png

[brutella]

Danke für die Rückmeldung. Somit ist 2.8.2 jetzt offiziell verfügbar.

[MikeR]

Perfekt, funktioniert genau so wie erwartet!

Vielen Dank für die schnelle Reaktion und die saubere Lösung
Mike

[brutella]

MikeR Hab jetzt das Problem mit dem Dekodieren als String DPT 16.000 und DPT 16.001 in 2.8.2-b2 behoben. Somit sollte ein einfacher Vergleich mit

msg == "*GO*"

funktionieren. Bitte ausprobieren – danke.

[MikeR]

Ja klar, war an der Stelle betriebsblind...
...und bin es wohl immer noch?

Die Parse-Funktionen sind doch dafür da aus dem Byte-Buffer einen String zu machen, also sieht mein Testcode so aus:

buf = <-oCh
msg1 = hkknx.ParseDPT16000(buf)
printf("Nach Parse: % X", msg1)
msg2 = msg1[1:]
msg3 = strings.TrimLeft(msg2, "\x00")
printf("Nach TrimLeft: % X", msg3)
msg4 = strings.TrimRight(msg3, "\x00")
printf("Nach TrimRight: % X", msg4)​

Das Ergbsnis bleibt

Nach Parse: 00 54 65 73 74 00 00 00 00 00 00 00 00 00 00
Nach TrimLeft: 54 65 73 74 00 00 00 00 00 00 00 00 00 00 <<- Das ist wegen dem Subarray korrekt, nicht wegen dem TrimLeft
Nach TrimRight: 54 65 73 74 00 00 00 00 00 00 00 00 00 00​

Das (nochmal nachträglich eingefügte) manuelle Beschneiden am Anfang mit dem Subarray klappt natürlich, die Trims nicht.

Komme mir gerade etwas unfähig vor!?!

[brutella]

Du musst den Text trimmen, nicht die Bytes.

[MikeR]

Seufz...

buf = <-oCh
msg = strings.TrimRight(buf,"\x00")
printf("% X",msg)​

...liefert bei einem über den Bus geschickten "Test" als hex ein "54 65 73 74 00 00 00 00 00 00 00 00 00 00". Der "TrimRight" tut als bei TrailingZeros nicht was man von im erwartet.

[MikeR]

Wäre es da nicht auch in der Parser-Funktion sinnvoll die Nullen am Ende zu eliminieren, wenn die immer dabei sind.
Mag an einer Beschränkung meinerseits liegen, aber ich kann mir nicht vorstellen, dass jemand über das eh schon suboptimal DPT16 auch noch mit Absicht Nullen schicken will!?!

[brutella]

Ich hab mir dein Problem mal etwas näher angesehen und zu möglichen Lösungen gekommen. → https://go.dev/play/p/oUuturdL15A

Lösung 1. Du verwendest `strings.HasPrefix(msg, "*GO*")`
Lösung 2 (Mein Favorit). Du löscht alle nachführenden Nullen mit `strings.TrimRight` und überprüfst dann wie gewohnt mit `msg == "*GO*"`

Also

var trimmed = strings.TrimRight(msg, "\x00")
if trimmed == "*GO*" {
    ...
}

Bzgl. hkknx.ParseDPT16000 hast du Recht. Die zusätzliche Null am Beginn scheint ein Fehler zu sein. Werde ich in einem Update beheben.

[MikeR]

P.S.: Ich habe das "hkknx.ParseDPT16000()" raus geschmissen, weil mir das noch eine zusätzliche führende Null erzeugte

[MikeR]

Ja, das stimmt. Danke für den Tipp mit der HEX-Ausgabe.
Ich bekomme IMMER ein 14-byte großes Zeichen-Array, das am Ende des Payload-Textes mit Nullen aufgefüllt ist. In meinem Fall also "2A 47 4F 2A 00 00 00 00 00 00 00 00 00 00".

Ich könnte natürlich Einfach ein msg[0:4] auf "*GO*" prüfen, ist aber auch nicht schön.

Ein "msg = strings.TrimRight(buf, '\000')" trimmt nix, und ein "strings.Index(msg,'\000')" liefert -1 für nicht gefunden. Würde gerne die Nullen irgendwie loswerden, anstatt implizite Annahmen über Längen zu machen.

Aber wenn keiner mehr eine Idee hat, dann bleibe ich beim dem Sub-Array

Besten Dank und liebe Grüße aus Wiesbaden
Mike

[brutella]

Hallo zusammen,

erstmal ein extrem großes Lob, an den Entwickler. Bin zwar noch am Testen, weil ich nicht so viel Zeit habe auch schon länger. Aber jedes mal wenn ich mich dran setze, bin ich echt begeistern und werde das Paket auch kaufen. Man sieht und "fühlt" was da an Arbeit drin steckt, plus dem Support. Dafür ist der Lizenzpreis absolut geschenkt!!!

Vielen Dank für die netten Worte – das freut mich. ❤️

[...]die Erkennung des Terminierungssymbols "*GO*" bekomme ich nicht hin[...]

Versuch mal testweise den empfangenen Wert ins Log auszugeben.
Entweder die Message als Text

println(msg)

oder am Besten als Hexwert

printf("% X", msg)

ausgeben. Womöglich empfängst du einen anderen Text als erwartet oder vielleicht sind noch irgendwo Bytes darin versteckt, die du so nicht erwartest.

[MikeR]

Das ist eine gute Idee. Bei einer OO-Sprache sollten die Operatoren ja entsprechende Überlastungen haben, aber ich kenne Go ja auch nicht.

Ich Probier das heute Nacht mal, wenn ich das jetzt mache killt mich meine Frau.

[knxPaul]

Ein Ansatz ist noch zwei Variablen anzulegen mit Inhalt "*GO*" und dann zu vergleichen

if (msg == varGO)​

Damit wird zumindest klarer, ob ein Inhaltsvergleich oder der Vergleich der Pointer ausgeführt wird.