OpenKNX-Logikmodul release

[mumpf]

gibt es eine Möglichkeit im Logikmodul eine Einschaltverzögerung mit berechnetem Wert (in Sekunden) zu belegen?

Man bekommt das hin, aber es ist keine fertige Funktion. Ich hab in der Doku ein Beispiel für einen Betriebsstundenzähler (der zählt aber die Sekunden). Den könnte man jetzt immer runter zählen lassen, sobald ihm ein Sekundenwert gesetzt wird und bei 0 stoppen und eine Aktion auslösen. Mit dem neusten Logikmodul 3.3 geht das noch einfacher, weil jetzt Zähler ohne Rückkopplung auf den Eingang möglich sind und so versehentliche Schleifen vermieden werden.

Also: Es wird gehen, aber man muss die passende Logik parmetrisieren und sie wird sicherlich aus mehreren Kanälen bestehen. Schau Dir das Zählerbeispiel in der Doku an und versuch es zu verstehen. Wenn Du noch Fragen hast, melde Dich einfach.

Gruß, Waldemar

[kleinklausi]

Hallo,

gibt es eine Möglichkeit im Logikmodul eine Einschaltverzögerung mit berechnetem Wert (in Sekunden) zu belegen?

Hintergrund: ich will für ein Fenstermotor Positionsfahrten nachbauen. Der Motor wird über zwei Kontakte (Impulssteuerung) Auf und Zu gesteuert. Wobei ein weiteres Auf während der Fahrt den Motor stoppt (selbes für Zu). Ich muss also anhand der letzten Position und der anzufahrenden Position die Zeit berechnen und ein weiteres Telegramm senden.

Vielen Dank und Grüße!

[mumpf]

Sprich: Sensormodul v5 ohne LM aber auf SAMD.

Naja, das Sensormodul ist nicht so sehr von Erweiterungen betroffen. Auch im aktuellen Sensormodul (RP2040-Version) ist es ein verbesserter KNX-Stack und ein verbessertes Logikmodul, die zu einem Update führen. Im Sensormodul hat sich da nichts getan (außer einem UI-Redesign). Und genau die Änderungen am "Unterbau" sind es aber, die den SAMD "sprengen", da bleibt es also bei der bisherigen Infrastruktur.

Ich werde noch einen halbautomatischen Upgrade-Pfad für das Sensormodul anbieten (mit unserem neuen Konfigurationstransfer), wenn jemand die Hardware wechseln möchte. Und wenn noch irgendwo ein grober Bug entdeckt wird, für den es keinen Workaround gibt, dann würde ich den fixen.

Was ich nicht machen werde, ist neue Sensoren implementieren, falls das im neuen Sensormodul passieren sollte (ist nur hypothetisch, derzeit ist nichts geplant). Denn wer das SAMD-Modul verwendet, hat ja schon seine Sensoren dran, und die funktionieren ja. Und es sind recht viele möglich. Wer dann auf einen neuen Sensor wechseln will (falls es den mal gibt), müsste auch auf die neuere Hardware wechseln. Aber warum sollte man das machen? Temperatur bleibt Temperatur, egal von welcher Sensorgenaration gemessen .

Ich hoffe, das deckt das ab, was Du wissen wolltest?

Gruß, Waldemar

[mumpf]

Genau so... aber Du hast wahrscheinlich trotzdem einen Denkfehler drin .

Wenn Du (was wahrscheinlich ist) Kanal 1 mit Einschaltverzögerung programmiert hast, dann denkst Du, dass ein Trigger am Eingang 1 den Wert, der getriggert hat, auch speichert. Das ist aber nicht der Fall. Der Ausgangskonverter vom Kanal 1 wird z.B. nach 30 Sekunden getriggert, und dann macht er das, was in der Anleitung steht: Er gibt den Wert von Eingang 1 auf den Ausgang. Und zwar den AKTUELLEN Wert. Wenn das noch der ist, der getriggert hat, ist das prima, wenn es ein neuer Wert ist, dann gibt er diesen Wert aus. Es gibt keinen Speicher im Loigkmodul, nut die KOs, die man als Speicher nutzen kann.

Ich habe als Kanal 1 ein Tor, dass Auf- und sofort wieder Zugeht. Dadurch wird die aktuelle Luftfeuchte vom Eingang auf den Ausgang geschrieben. Das Tor wird jede Minute (per Zeitschaltuhr) getriggert, geht als jede Minute kurz auf. Damit hat man am Ausgang immer einen max. 1 Minute alten Wert.
Das Differenzintervall lasse ich nur vom Eingang der akt. Luftfeuchte triggern. Damit wird immer, wenn eine neue Luftfeuchte reinkommt, mit dem anderen Wert verglichen, der max. 1 Minute alt ist. So weißt Du, ob innerhalb der letzten Minute der Wert stark gestiegen ist.

Gruß, Waldemar

[henfri]

Ich werde jetzt erstmal den VPM mit der neuen Infrastruktur (und dem neuen Logikmodul) rausbringen (heute oder morgen), dann das Sensormodul (kommendes Wochenende). Beide aber nur für die RP2040-Hardware.

Das verstehe ich.

Die Frage ist, ob die SAMD Sensormodule mit dem alten Logikmodul weiter gepflegt werden können?
Sprich: Sensormodul v5 ohne LM aber auf SAMD.

[Sisamiwe]

mumpf willisurf

Hallo,

ich bräuchte mal Hilfe der Logikexperten, ich stehe auf dem Schlauch....
Ich versuche über den Anstieg der Luftfeuchtigkeit im Bad "Duschbeginn" zu detektieren.
Dazu habe ich an folgende Logik gedacht:
Kanal 1 hat als Eingang die Luftfeuchte und gibt diese nach einer Verzögerung von xx Sekunden an Kanal 2 weiter.
Kanal 2 macht ein Differenzintervall zwischen der verzögerten Luftfeuchte (Eingang 1 mit internem KO) und der Luftfeuchte (Eingang 2). Wenn die Differenz negativ ist (also die aktuelle Luftfeuchte größer als die verzögerte) dann schicke ein EIN.
Irgendwie klappt das nicht und ich finde den Fehler nicht.

Wie macht man das richtig?

[mumpf]

Ja, da arbeite ich gefühlt seit Wochen dran. Und habe jetzt schweren Herzens etwas beschlossen, wass einigen weh tun wird (ich weiß nicht, ob Du dazu gehörst), aber es geht nicht anders. Ich werde jetzt erstmal den VPM mit der neuen Infrastruktur (und dem neuen Logikmodul) rausbringen (heute oder morgen), dann das Sensormodul (kommendes Wochenende). Beide aber nur für die RP2040-Hardware. Es geht einfach nicht mehr mit dem SAMD. Ich habe wirklich mehrere Wochen lang (nicht am Stück, aber immer wieder) versucht, noch RAM zu sparen, um es hin zu bekommen. Aber es ist nicht stabil und der hängt sich immer wieder auf. Damit würde ich keinem eine Freude machen.

Natürlich dann das SAMD-Sensormodul noch in der alten Variante weiter betrieben werden, die ist durchaus robust und funktioniert zuverlässig, aber alle neuen Funktionen kosten einfach zu viele Ressourcen, dass es der SAMD noch schaffen kann.

In der ersten Runde wird das neue Sensormodul auch noch ohne 1-Wire-Unterstützung sein, das gibt es erst in ca. 2-3 Monaten, nach meinem Urlaub .

Gruß, Waldemar

P.S.: Das neue Logikmodul wird in alle Module Einzug halten, die ein Update rausbringen und ein Logikmodul anbieten, z.B. auch der neue Fingerprint...

[henfri]

Hallo,

danke für das neue Release!
Gibt es einen Plan, das im Sensormodul enthaltene Logikmodul auf diese Version zu aktualisieren?

Viele Grüße,
Hendrik

[mumpf]

Das wäre zumindest die Erklärung, warum es nicht hilft, die Länge mitzusenden und dazu passend eine andere Fehlermeldung zu generieren.

Was ist außerdem nicht verstehe: APDU ist hier 55, aber die Formel, die klappt, ist 63 Byte. Wieso klappt das?

Gruß, Waldemar

[traxanos]

Für mich Sicht das aus als würde der Befehl garnicht gesendet. Bei mir habe ich min 1 Telegramm mehr. Vg vermute, wenn es zu groß ist, wird es einfach nicht gesendet.

[thewhobox]

Was Marco meint ist das "FunctionPropertyInvoke" oder so ähnlich.
Das wäre interessant zu wissen, wie es auf der TP-Linie aussieht.

Auf der IP Seite kam bei meinen Test einfach Müll zurück in den restlichen Bytes.
Wie das auf TP-Seite aussieht weiß ich nicht.

[Sisamiwe]

Command dazu ist wichtig weil damit die Formel übertragen wird.

Das sind die Commands, die bei Formel prüfen ausgeführt werden:

#    Zeit    Dienst    Flags     Prio    Quelladresse    Quellname    Zieladresse    Zielname    Gebäudefunktion    Gebäudeteil    Hop Count    Typ    DPT    Info
13    11.07.2024 16:08:48,829    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    T_Connect        
14    11.07.2024 16:08:48,870    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    DeviceDescriptor_Read (S=0)        DescriptorType=0
15    11.07.2024 16:08:48,892    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    T_ACK (S=0)        
16    11.07.2024 16:08:48,923    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    DeviceDescriptor_Response (S=0)        DescriptorType=0, DescriptorData=07 B0
17    11.07.2024 16:08:48,970    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    T_ACK (S=0)        
18    11.07.2024 16:08:49,021    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    PropertyValue_Read (S=1)        ObjectIndex=0, PropertyId=56, Count=1, StartIndex=1
19    11.07.2024 16:08:49,041    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    T_ACK (S=1)        
20    11.07.2024 16:08:49,084    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    PropertyValue_Response (S=1)        ObjectIndex=0, PropertyId=56, Count=1, StartIndex=1, Data=00 FE
21    11.07.2024 16:08:49,146    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    T_ACK (S=1)        
23    11.07.2024 16:08:49,383    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    T_ACK (S=2)        
24    11.07.2024 16:08:49,414    vom Bus        System    1.0.201    OpenKNX: Soundmodul    1.0.255    -            6    FunctionPropertyState_Response (S=2)        ObjectIndex=160, PropertyId=4, ReturnCode=255
27    11.07.2024 16:08:50,471    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    T_ACK (S=2)        
28    11.07.2024 16:08:50,511    zum Bus        System    1.0.255    -    1.0.201    OpenKNX: Soundmodul            6    T_Disconnect    ​

Details zu #14:

Eigenschaft	Wert
RawData	2E 00 B0 60 10 FF 10 C9 01 43 00
MessageCode	L_Data_con
Source	1.0.255
SourceName	-
Destination	1.0.201
DestinationName	OpenKNX: Soundmodul
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	zum Bus
LocalizedType	DeviceDescriptor_Read (S=0)
Security
SequenceNumber	0
TPCI	T_Data_Connected
APCI	DeviceDescriptor_Read
DescriptorType	0

#16:

Eigenschaft	Wert
RawData	29 00 B0 60 10 C9 10 FF 03 43 40 07 B0
MessageCode	L_Data_ind
Source	1.0.201
SourceName	OpenKNX: Soundmodul
Destination	1.0.255
DestinationName	-
RepeatedFlag	False
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	vom Bus
LocalizedType	DeviceDescriptor_Response (S=0)
Security
SequenceNumber	0
TPCI	T_Data_Connected
APCI	DeviceDescriptor_Response
DescriptorType	0
DescriptorData	07 B0

#18

Eigenschaft	Wert
RawData	2E 00 B0 60 10 FF 10 C9 05 47 D5 00 38 10 01
MessageCode	L_Data_con
Source	1.0.255
SourceName	-
Destination	1.0.201
DestinationName	OpenKNX: Soundmodul
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	zum Bus
LocalizedType	PropertyValue_Read (S=1)
Security
SequenceNumber	1
TPCI	T_Data_Connected
APCI	PropertyValue_Read
PropertyObjectIndex	0
PropertyId	56 (PID_MAX_APDULENGTH)
PropertyCount	1
PropertyStartIndex	1

#20

Eigenschaft	Wert
RawData	29 00 B0 60 10 C9 10 FF 07 47 D6 00 38 10 01 00 FE
MessageCode	L_Data_ind
Source	1.0.201
SourceName	OpenKNX: Soundmodul
Destination	1.0.255
DestinationName	-
RepeatedFlag	False
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	vom Bus
LocalizedType	PropertyValue_Response (S=1)
Security
SequenceNumber	1
TPCI	T_Data_Connected
APCI	PropertyValue_Response
PropertyObjectIndex	0
PropertyId	56 (PID_MAX_APDULENGTH)
PropertyCount	1
PropertyStartIndex	1
PropertyData	00 FE

#23

Eigenschaft	Wert
RawData	29 00 B0 60 10 C9 10 FF 00 CA
MessageCode	L_Data_ind
Source	1.0.201
SourceName	OpenKNX: Soundmodul
Destination	1.0.255
DestinationName	-
RepeatedFlag	False
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	vom Bus
LocalizedType	T_ACK (S=2)
Security
SequenceNumber	2
TPCI	T_ACK

#24

Eigenschaft	Wert
RawData	29 00 B0 60 10 C9 10 FF 04 4A C9 A0 04 FF
MessageCode	L_Data_ind
Source	1.0.201
SourceName	OpenKNX: Soundmodul
Destination	1.0.255
DestinationName	-
RepeatedFlag	False
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	vom Bus
LocalizedType	FunctionPropertyState_Response (S=2)
Security
SequenceNumber	2
TPCI	T_Data_Connected
APCI	FunctionPropertyState_Response
PropertyObjectIndex	160
PropertyId	4 (PID_GROUP_OBJECT_REFERENCE)
ReturnCode	255
CommandData

[traxanos]

Ne das Command dazu ist wichtig weil damit die Formel übertragen wird.

[Sisamiwe]

RawData Inhalt wäre interessant.

Eigenschaft	Wert
RawData	29 00 B0 60 10 C9 10 FF 04 4A C9 A0 04 FF
MessageCode	L_Data_ind
Source	1.0.201
SourceName	OpenKNX: Soundmodul
Destination	1.0.255
DestinationName	-
RepeatedFlag	False
Acknowledge	Ack
HopCount	6
Priority	System
FrameFormat	Standard
Service	vom Bus
LocalizedType	FunctionPropertyState_Response (S=2)
Security
SequenceNumber	2
TPCI	T_Data_Connected
APCI	FunctionPropertyState_Response
PropertyObjectIndex	160
PropertyId	4 (PID_GROUP_OBJECT_REFERENCE)
ReturnCode	255
CommandData

[traxanos]

Über den Busmonitor in der ETS selber. Erkennst du daran das der Typ "FunctionPropertyCommand" ist und die ObjectIndex=160 ist. RawData Inhalt wäre interessant.