ESP8266 KNX mit ETS

[wladw]

Ich nutze PlattformIO, da get es mit #define über Compiler Anweisung in Plattform.ini: -DMASK_VERSION=0x27B0.

Aber ich versuche erstmal wie es ist mit RF. Die Frage ist ob die Ausgabe, die ich gepostet habe und ETS Verhalten so wie es sein soll (weil ich de facto kein RF Tranceiver dran habe), oder muss eigentlich mehr passieren.

Und KNX-USB Beispiel ist wohl nicht so einfach auf TP zu ändern, da kommen dann viele Fehlermeldungen beim Kompilieren, dass rf Anteile nicht existieren, ich denke wegen diesem hier: https://github.com/thelsing/knx/issues/55

[Ing-Dom]

hast du die config.h im Stack angepasst?

// Normal devices
// TP1: 0x07B0
// RF: 0x27B0
// IP: 0x57B0
#define MASK_VERSION 0x07B0
//#define MASK_VERSION 0x27B0
//#define MASK_VERSION 0x57B0

[wladw]

(EDIT: Gelöst, lag vermutlich daran, dass kein RF Interface dran war)

Hallo, vielelicht kann jemand meine Frage beantworten:

HW: Adafruit ItsyBitsy M0 mit SAMD21 (nichts sonnst dran)
SW Umgebung: PlattformIO
Anwendung: knx-usb Beispiel aus knx Library von thelsing

Habe kompiliert (davor im Beispiel Serial1 auf Serial geändert, weil sonst am Serial nichts rauskommt - wohl für Adafruit ItsyBitsy M0 spezifisch) und geflasht. Wenn ich ETS 5.7.6 Demo nun öffne, erscheinnt da Schnittstelle "KNX RF - USB Interface (KNX Association)". So weit gut. Wenn ich drauf klicke, kommt nach einer Zeit Fehlermeldung "Es wurde versucht eine nicht existierende oder schreibgeschützte Stelle zu schreiben". Gleichzeitig im
in PlattformIO:

Device Feature Get: Supported EMI types
Device Feature Set: Active EMI type: 03
M_PropWrite_req: ObjType: 8 ObjInst: 1 PropId: 52 NoE: 1 startIdx: 1 -> data: 00
<- no error
M_PropRead_req: ObjType: 8 ObjInst: 1 PropId: 52 NoE: 1 startIdx: 1 <- data: 00

M_PropRead_req: ObjType: 0 ObjInst: 1 PropId: 58 NoE: 1 startIdx: 1 <- data: 00

M_PropRead_req: ObjType: 0 ObjInst: 1 PropId: 57 NoE: 1 startIdx: 1 <- data: 00

M_PropRead_req: ObjType: 8 ObjInst: 1 PropId: 51 NoE: 1 startIdx: 1 <- data: 00 10

M_PropRead_req: ObjType: 0 ObjInst: 1 PropId: 82 NoE: 1 startIdx: 1 <- error: 07

M_PropRead_req: ObjType: 0 ObjInst: 1 PropId: 56 NoE: 1 startIdx: 1 <- data: 00 0F

M_PropRead_req: ObjType: 0 ObjInst: 1 PropId: 82 NoE: 1 startIdx: 1 <- error: 07

M_Reset_req: sending M_Reset_ind
save saveRestores 4
-10
.
-28
.
-39
.
-39
.
save tableobjs 4
-39
.
-55
.
-66
.
-77
.
SAVED 00 FA 00 00 00 00 00 00 00 03 FF FF 00 01 00 00 01 60 00 01 00 00 00 00 00 00 00 00 00 01 00 00 01 FF FF FF FF FF FF D0 35 00 20 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF
FF FF FF

Frage: Ist das normal oder muss mehr/was anderes passieren?

Frage Nr2: Eigentlich will ich TP und nicht RF: muss ich dazu vom Bau27B0 auf Bau07B0 ändern (habe schon versucht) und dann aus cEMI alle Zeilen auskommentieren, wo der Compiler wegen Referenz zu RF Fehler findet, oder? Oder hat das noch keiner versucht mit KNX TP-USB ...

[mumpf]

Danke erstmal.

Der von Dir beschriebene Fall ist klar (verwende ich ganz häufig). Wenn 2 KO über eine GA verbunden sind, bekommen sie den gleichen Wert.

Ich wollte wissen, ob es sich genau so verhält, wenn die 2 KO NICHT über eine GA verbunden sind, und ich nur intern in beide KO den gleichen Wert schreibe. Sprich, bekomme ich die gleichen Events, wenn ich selber schreibe anstatt dass der Wert über eine GA kommt.

Ich will mir in bestimmten Fällen die GA sparen und nur intern kommunizieren, aber es soll sich so verhalten, als ob eine GA da wäre. Letztendlich will den Bus weniger belasten und keine GA in der ETS anlegen müssen.

Gruß, Waldemar

[thesing]

Ich bin mir nicht ganz sicher, ob ich die Frage verstanden habe .

Wenn zwei KO über eine GA verbunden sind wird das intern auch übermittelt. D.h. KO1 und KO2 haben die gleiche GA. Du schreibst und KO1 und sendest, Dann hat KO2 den gleichen Wert. Was unabhängig davon in die KOs schreibst bleibt dir überlassen.

[mumpf]

Hi,

ich hab mal wieder eine konzeptionelle Frage zum Stack...

Ich hab schon öfter erwähnt, dass ich an einem Logikmodul schreibe. Ich habe vorgesehen, dass der Ausgang eines Logikkanals intern auch als Eingang eines weiteres Kanals genutzt werden kann. Was diesem Konstrukt fehlt, ist Eventing, es verhält sich nicht wie Telegramme (wird eben nur statisch abgefragt) und ist somit ein Bruch in dem eigentlichen Logikkonzept. Bevor ich das Ganze jetzt aufwändig umschreibe, wollte ich Fragen, ob ich den Stack dafür folgendermaßen nutzen könnte:

Jede Logik hat 2 Eingänge und 1 Ausgang und somit 3 KO. Nehmen wir mal an, ich habe 2 Logiken L1 und L2, beide AND, diese sollen zu einem 3-fach AND verbunden werden L2(L1(A, B), C).

Wenn ich jetzt beim Schreiben ins Ausgangs-KO von L1 gleichzeitig ein Eingangs-KO von L2 beschreibe (algorithmisch), verhält sich das dann genau so, als wenn ich die beiden KO über eine GA verbunden hätte? Und klappt das auch, wenn die beiden KO keine GA zugeordnet haben?

Ich weiß, ich kann das ausprobieren. Das werde ich auch, wenn nicht z.B. thesing gleich sagt, das kann nicht klappen. Ich müsste dafür einiges an meiner Struktur ändern und würde mir das sparen, wenn es sowieso hoffnungslos ist.

Wenn ich so vorgehen könnte, hätte ich den Vorteil das "interne" KO-Zuordnungen sich genau so wie externe verhalten würden. Ich könnte somit auch andere KO (z.B. Sensorwerte) intern verfügbar machen.

Gruß, Waldemar

[Ing-Dom]

die tu wien sollte die AN177 haben..

[Nanosonde]

AN177.
Auf welcher Basis hast du die Methoden in deinen Stack integriert?

Die AN177 ist ja leider nicht verfügbar.

Ich habe daher hier nachgeschaut: https://github.com/calimero-project/...ier.java#L1041

[thesing]

Das war nicht ich, sondern Nanosonde .

[Ing-Dom]

Das steht wohl in einer Application Note.

AN177.
Auf welcher Basis hast du die Methoden in deinen Stack integriert?

[thesing]

In der verfügbaren spec steht von ExtMemory* Methoden übrigens nix drin. Das steht wohl in einer Application Note.

[thewhobox]

Ich hab grad mal nachgeschaut. Und das ist echt interessant!

Der Parameter M-0083_A-00A2-10-6169_P-324_R-1539 ("Schaltzeiten im Gerät") ist dafür da, damit man beim Parametrieren auswählen kann, ob die eingestellten Schaltzeiten im Gerät erhalten bleiben oder überschrieben werden sollen.

<ParameterType Id="M-0083_A-00A2-10-6169_PT-ZSU.5FProgrammEnable" Name="ZSU_ProgrammEnable">
    <TypeRestriction Base="Value" SizeInBit="8">
        <Enumeration Text="will be transmitted" Value="0" Id="M-0083_A-00A2-10-6169_PT-ZSU.5FProgrammEnable_EN-0" />
        <Enumeration Text="remain unchanged" Value="1" Id="M-0083_A-00A2-10-6169_PT-ZSU.5FProgrammEnable_EN-1" />
    </TypeRestriction>
</ParameterType>

Somit sind die 96 Bytes, die in der MergeId=4 quasi ausgelassen werden, für die Schaltzeiten die man am Gerät einstellen kann reserviert.

Das schließt aber gleichzeitig auch ein Partielles Parametrieren am Anfang aus, da der Speicher in MergeId=2 nicht komplett mit 0x00 überschrieben wird.
Erst später wenn der MCB bekannt ist, kann schneller parametriert werden.

[Ing-Dom]

Ggf. spart man durch den Verzicht des Ladens umfangreicher Parametrierungen für ein nicht aktiviertes Feature Zeit?

Aber wenn ich euch richtig verstanden habe, werden Parameter die nicht eingeblendet sind auch nicht geladen? Dann wäre das wieder Blödsinn...

[thewhobox]

Crashkurs geben

ich bringe dir gerne alles bei, was ich weiß (ist aber auch nicht komplett)

Ladeprozeduren bilden ja nur ab, wann, wie und was in den Speicher des Gerätes geschrieben wird.
Wofür man genau da ein choose braucht hat sich mir auch noch nicht ganz erschlossen^^

[mumpf]

Tja, an sich würde ich das cool finden... wenn ich wüsste, was die LoadProcesures machen.

Du musst mir mal bei Gelegenheit einen Crashkurs geben, was die machen, dann würde ich vielleicht endlich verstehen, was ich da mache und warum das funktioniert . Und dann könnte ich auch Ideen entwickeln, wofür man an der Stelle ein choose brauchen könnte.

Gruß, Waldemar