schön zu hören, dass es jetzt geht.
Mit meiner Vermutung bzgl. der sblib war ich wahrscheinlich etwas zu voreilig.
Das Problem ist in der app_out8.cpp (ich habe mal meine patch-Datei angehängt).
Ich sitze z.Zt. sowieso an der out8 u.a. auch noch an dem Problem Busspannungsausfall.
Wird allerdings noch ein Weilchen dauern bis alles rund ist, da dieses Weihnachten ja noch ansteht .
...hab mir mal die Lib angesehen, denke in der SendNextGroupTelegram Funktion ist der Fehler:
if (flags & COMFLAG_DATAREQ)
sendGroupReadTelegram(objno, addr);
else if (config & COMCONF_TRANS)
sendGroupWriteTelegram(objno, addr, false);
else continue;
alleine aus dem COMFLAG "data request flag (bit2 vom RAM FLAG)" läßt sich nicht ableiten ob die App eine read-request oder write-request auf den Bus schickt, dazu werden die transmit status flags (bit0, bit1 vom RAM FLAG) genutzt. Das Config Flag Transmit-enable kann nicht von der Lib als Indikator für ein write-request genutzt werden (sagt nur aus, ob die App ein write-req oder read-req senden darf und wird mit der ETS gesetzt).
Da ich die Struktur der Sw noch nicht durchdrungen habe, sollte sich der Entwickler das nochmal ansehen ( ob die Flag richtig von der App und der Lib gesetzt und bewertet werden).
Hallo Denis,
dein patch ist auch korrekt, write request telegram wird nur bei update vom obj. geschickt (gilt das auch für Handsteuerung?).
Ein Read-req darf die Lib nicht senden wenn das Transmit-enable nicht gesetzt ist.
LG
Horst
Hallo Denis,
mit deinem objectwrite hast du, wenn ich mich nicht täusche, eine Loop in der Lib aufgedeck. Die Funktion <processGroupTelegram(..)> in com_objects.cpp prüft über die association-table auf Basis der Grp-addr (welche vorher von der Funktion <sendNextGroupTelegram()> auf Basis des Objects ermittelt wurde) welche Objekte über ein write_req. vom App-layer informiert werden müssen und setzt dazu das update Flag im RAM-Flag des entsprechenden Objekts. Dabei werden alle Associations der Grp-addr informiert, so auch die des Objekts, das diesen write_req. generiert hat. In der App wird dann das Update Flag wieder geprüft und erneut eine objectwrite getriggert. Die Funktion <processGroupTelegram(..)> sollte keinen service request an das aufrufende Object aus der App senden (anders als beim Empfang vom Bus, da gibts noch keine obj info, nur Grp-addr aus Bus-Telegram). Das sollte dort entsprechend geprüft werden (KNX Spec Vol3, part3, chapter7, Abschnitt 3.1. App Layer services)
Wieso sendest du eigentlich ein Object-value (1-8), denke, dass nur die Rückmeldeobjekte bei Bedarf gesendet werden sollten.
einen Loop in der sblib hatte ich auch zuerst vermutet, hatte allerdings bisher keine Zeit es mir genauer anzuschauen.
hora0816 hat geschrieben: ↑21. Dez 2020, 20:18
Wieso sendest du eigentlich ein Object-value (1-8), denke, dass nur die Rückmeldeobjekte bei Bedarf gesendet werden sollten.
Das hält intern den Zustand des Schaltobjekts auch wenn das Relais einen anderen Zustand wegen Timing/Logik hat. Ist zumindest bisher meine Vermutung, da der ursprüngliche Code nicht von mir ist.
Grüße
Denis
5x in16-bim112 ARM | 1x rol-jal-bim112 ARM | 2x MSA | 1x raincenter-bim112 ARM | 8x Kombisensor LPC | 1x out8 LPC | 2x 2in2out LPC
Hallo Denis,
hab die Logik noch nicht angeschaut, denke die Werte der Objekte können von 2 Triggern geändert werden: Telegramme vom Bus (über das Interface zur Lib) und Handsteuerung (in der App).
* Telegramme vom Bus (bzw. über andere Objekte mit gleicher Grp-adr., das ist ja die Loop) kommen über das update Flag und den entsprechenden ObjectValue im RAM.
* Änderungen über die Handsteuerung sollten den ObjectValue ändern und dann mit ObjectWrite die entsprechenden Grp-Adr (am Bus und in der App) updaten. Damit ist auch gewährleistet, dass Schaltobjekte in anderen Aktoren mit der gleichen Gruppenadresse den gleichen Status erhalten und entsprechend schalten. M.E. ist es nicht erforderlich bei empfangenem Object update (egal ob vom Bus oder über eine Grp-Adr. der App) auch ein ObjectWrite zu senden. Der temporäre Objekt Staus durch die ggf verzögerte/gepulste Ansteuerung der Relais sollte an der Schnittstelle zwischen App und Lib (Ram-Flags, ObjectValue) nicht auftauchen.
* Sind die Rückmeldeobjekte aktiviert (transmit) sollten diese bei Änderungen der Schaltobjekte entsprechend gesetzt/gesendet werden. Das kann/sollte erfolgen, wenn die Relais auch wirklich geschaltet haben.
.