Ankündigung

**JuMi2006** · 26.02.2014, 21:58

Hallo Max,

ich hatte heute mal ne Stunde um mich beim Arduino damit zu befassen. Die erste Übung war das setzen der PA. So ganz diskussionslos finde ich das nicht, aber ist eigentlich schnell geklärt.

Die PA habe ich im EEPROM abgelegt und beim Start wieder ausgelesen, das funktioniert soweit auch. Mir geht es eher darum ob wir uns darauf einigen bestimmte EEPROM-Bytes "standardisiert" zu verwenden. Ich bin gerade dabei einen KNX-Skeleton-Sketch zu erstellen. Für die Multiplikation von Anwendungen fände ich einen Standard dort sehr hilfreich.

Ich könnte mir folgendes vorstellen:

EEPROM[0-2]: Physikalische Adresse
EEPROM[3,4]: MaskVer
EEPROM[x]: to be continued

Damit kann man dann einen definierten Adressbereich fürs Mappen, Flags und Parameter garantieren. Diese Werte sollten doch m.W. eher dynamisch aber persistent sein.

Hat mit dem Programm zugegeben recht wenig zu tun, aber gehört irgendwie dahin. Zum Rest muss ich mich erst nochmal mit dem BCU2 Helpfile beschäftigen um das zu verinnerlichen.

Grüße

**dreamy1** · 26.02.2014, 22:09

Also für mich ist noch nicht klar, ob man bei DIY-Geräten *wirklich* über den Bus konfigurieren muss.

Das kann auch von der Anforderung abhängen - Beispiel: ein T/H-Sensor, der alle 30s die beiden Messwerte auf den Bus schreibt, wird i.d.R. einmal in Betrieb genommen und läuft durch. Also reicht da 1x Flashen des µC, einbauen und vergessen. An der GA-Struktur ändert man auch nicht dauernd rum, also hat das vermutlich lange oder bis zum EOL Bestand.

Das kann bei DIY-Geräten mit höherer Intelligenz anders aussehen. Hier werfe ich auch mal die Idee in den Raum, ohne ETS oder sonstiges Tool einfach eine Konfiguration per SD-Karte vorzunehmen...so habe ich das jedenfalls bei einem meiner nächsten Arduino-Ergüsse geplant :-)

Vorteil: kann jeder mit umgehen, läuft auch per OS-Wechsel o.ä., betriebssystemunabhängig, kaum Mehrkosten. In der Praxis stelle ich mir das so vor: SD-Karte mit den Konfidaten einschieben, Knopf drücken, fertig. Beim Drücken des Tasters werden die Daten von der SD-Karte ins EEPROM geschrieben, die Karte kann also wieder entfernt werden. Idiotensicher.

**l0wside** · 26.02.2014, 22:31

Datenstruktur für DIY-Geräte

1. Grundlagen zu möglichen Konfigurationsschnittstellen

DeviceDescriptor (auszulesen über MaskVersionRead, Octet 6/7 = 0x30), fixer Wert, 2 Octets.
Properties (zu lesen über PropertyValue_Read/_Response, zu schreiben über PropertyValue_Write). Diese haben folgende Struktur:
- 1. Ebene: Object. Objects haben eine Nummer zwischen 0 und 255. Sie enthalten eine oder mehrere Properties.
- 2. Ebene: Property. Properties haben ebenfalls eine Nummer zwischen 0 und 255. Jede Property kann eine unterschiedliche Länge haben - von 1 Octet (d.h. Byte) bis zur praktischen Grenze von 10 Octets (mehr passen in einen Standard-Frame nicht rein, mit Extended Frames geht wohl auch mehr)
- 3. Ebene: Index. Jede Property kann mehrere Einträge haben. Das ist z.B. sinnvoll, um die Association Table von KO zu GA zu speichern.
PropertyDescription. Damit kann das Gerät nähere Informationen zu einer Property geben. Konkret enthält der Antwortframe Angaben zu Typ, Anzahl Elemente und notwendigem Access Level.
Access Level/AuthorizeRequest. Damit kann man dem Gerät einen 32 Bit langen Schlüssel schicken, der einen bestimmten Access Level freischaltet. Je nach Access Level ermöglicht das Gerät den Zugang zu bestimmten daten lesend oder schreibend.
Für die Anwendung zu Hause mäßig sinnvoll, da per Busmonitor leicht mitzulesen, aber für Werksanwendungen sicher sehr hilfreich. Keys werden trotzdem meistens bei Konfigurationen kommerzieller Geräte verwendet, vermutlich, um versehentliche Zugriffe zu verhindern.
MemoryRead/Write. Damit kann man direkt auf Speicherbereiche des Geräts zugreifen. In älteren Geräten wurde das standardmäßig für die Konfiguration genutzt, heute verwendet man eher die Properties.
UserMemoryRead/Write. Ist ein separater Befehl und könnte ebenfalls genutzt werden. Praktisch ist er mir aber noch nie untergekommen.

2. Mögliche Basis: die BCU2
Robert hat auf die BCU2, die Martin Kögler verwendet, hingewiesen. Dort sind einige Werte vorgegeben, auf denen man aufsetzen kann. Siehe hier.
Einige Objekte sind dort vordefiniert (alle folgenden Werte sind dezimal; jeweils 1 Element, wenn nicht anders angegeben):

Device Object (Object 0)
- Property 1: OBJECT_TYPE, unsigned int, readonly (immer 0)
- Property 8: SERVICE_CONTROL, unsigned int (hier kann man die einzelnen Layer ein- und ausschalten)
- Property 9: FIRMWARE_REVISION, unsigned char, readonly
- Property 11: SERIAL_NUMBER, 6 octets
- Property 12: MANUFACTURER_ID, unsigned int, siehe Herstellerkennungen
- Property 14: DEVICE_CONTROL, unsigned char (Bits für: run/stop, Framefehler, Verify Mode)
- Property 15: ORDER_INFO, 10 Octets (Bestellnummer)
- Property 16: PEI_TYPE, unsigned char, readonly (verwendeter Busankoppler)
- Property 17: PORTADDR, unsigned char (für direkte Ansteuerung von Ausgängen/Eingängen)
- Property 18: POLL_GROUP_SETTINGS (3 Octets, nur für Fast Poll relevant)
- Property 19: MANUFACTURE_ID, 4 octets (herstellerspezifische Kennung)
Address Table Object (Object 1)
- Property 1: OBJECT_TYPE, unsigned int, readonly (immer 1)
- Property 5: LOAD_STATE_CONTROL, 1 octet (nicht geladen, geladen, Laden läuft, Fehler)
- Property 7: TABLE_REFERENCE, unsigned int, Zeiger in den Speicher auf den Address Table (der dann per MemoryRead/Write bearbeitet werden kann)
  Diese Address Table enthält eine Liste von GAs.
Association Table Object (Object 2)
- Property 1: OBJECT_TYPE, unsigned int, readonly (immer 2)
- Property 5: LOAD_STATE_CONTROL, 1 octet (nicht geladen, geladen, Laden läuft, Fehler)
- Property 7: TABLE_REFERENCE, unsigned int, Zeiger in den Speicher auf den Association Table (der dann per MemoryRead/Write bearbeitet werden kann)
  Dieser Association Table enthält das Mapping von KO auf GA-Index im Address Table.
Application Program Object (Object 3)
- Property 1: OBJECT_TYPE, unsigned int, readonly (immer 3)
- Property 5: LOAD_STATE_CONTROL, 1 octet (Applikation nicht geladen, geladen, Laden läuft, Fehler)
- Property 6: RUN_STATE_CONTROL (Halted/Running/Ready/Terminated)
- Property 7: TABLE_REFERENCE (unsigned int, Zeiger auf den Speicher mit den KOs)
- Property 13: APPLICATION_VERSION (5 octets)
- Property 16: PEI_TYPE, erforderlicher Busankoppler

3. Umsetzungsvorschlag (zur Diskussion)
Gegenüber dem BCU2-Ansatz würde ich einige Dinge ändern:

In der BCU2 von Martin Kögler ist die Trennung Busankoppler/Gerät klar erkennbar, wo ein Teil der Software im Busankoppler läuft und dann über das PEI-Interface das eigentliche Gerät anspricht. Bei allen Projekten, die ich hier im Forum gesehen habe, wird ein integrierter Busankoppler verwendet, auch mein Stack unterstützt nur die integrierte Variante.
Speicherzugriffe sind aus meiner Sicht nicht gut und auch nicht notwendig. Alles Notwendige lässt sich über Properties regeln.
Das doppelte Mapping KO->Index->GA ist ein Schritt zu viel. Ein direktes Mapping KO->GA ist effizienter.
Manche Properties der BCU2 können auch schlicht entfallen.

Folgendes Subset schlage ich zur Implementierung vor:

Object 0: OBJECT_TYPE, FIRMWARE_REVISION, SERIAL_NUMBER, MANUFACTURER_ID, DEVICE_CONTROL, ORDER_INFO, MANUFACTURE_ID (alle Werte readonly)
Object 1: OBJECT_TYPE. Außerdem gibt´s in Property 2 eine Liste der verfügbaren KO (readonly).
Object 2: nicht unterstützt (wenn, dann für Kompatibilität emuliert)
Object 3: OBJECT_TYPE, RUN_STATE_CONTROL, APPLICATION_VERSION (alle Werte readonly)

Alle Konfigurationsdaten gehören ansonsten zu ihren KO. Dabei gilt: Objektnummer = KO. KOs müssen im Bereich 10...254 liegen. 0..9 ist reserviert aus Kompatibilitätsgründen, 255 ist reserviert für Debuggingzwecke.
Innerhalb des Objekt ist dann:

Property 0, Index 0: Flags
Property 0, Indizes 1..n: GAs
Property 1..n: Konfigurationsdaten

Beispiel (Temperatur-/Feuchtesensor):
KO 10: Temperatur, KO 20: Feuchte. Temperatur soll alle 60 Sekunden gemessen werden, Feuchte alle 120 Sekunden. Temperatur geht auf GA 1/1/1, Flags KLÜ, Feuchte geht auf GA 1/3/5 und 1/3/6 und wird nur gesendet (Flags KÜ).

Object 1, Property 2: Index 1=10, Index 2=20 (Liste der verfügbaren KO)
Object 10, Property 0, Index 0: 0x0B (=KLÜ, siehe hier)
Object 10, Property 0, Index 1: 0x0901 (1/1/1, zur Umrechnung z.B. hier)
Object 10, Property 0, Index 2...7: 0x00 (= nicht belegt, GA 0/0/0 ist nicht zulässig, da Broadcast)
Object 10, Property 1, Index 1: 60 (=60 Sekunden Intervall)
Object 20, Property 0, Index 0: 0x0A (=KÜ)
Object 20, Property 0, Index 1: 0x0B05 (GA 1/3/5)
Object 20, Property 0, Index 2: 0x0B06 (GA 1/3/6)
Object 20, Property 0, Index 3...7: 0x00 (= nicht belegt)
Object 20, Property 1, Index 1: 120 (=120 Sekunden Intervall)

Ich bitte um Kommentare.

**greentux** · 26.02.2014, 22:31

Wären ja vl. auch nur verschiedene Backends.
Man könnte via Bus (in welcher Form auch immer), man könnte via SD-Card, oder oder.

**l0wside** · 26.02.2014, 22:44

PC-Seite: Konfigurationsbeschreibung

Anmerkung: die Konfigurationsbeschreibung spiegelt noch nicht 1:1 die Vorschläge aus dem letzten Posting wieder. Je nach Ergebnis sind her noch Anpassungen notwendig.

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<device-config>
    <device-manufacturer>Kalassi</device-manufacturer>
    <device-name>Multisensor</device-name>
    <device-manufacturer-id>004C</device-manufacturer-id>
    <application-versions>
        <version>001234560801</version>
        <version>001234560802</version>
    </application-versions>
    <objects>
        <object id="10" name="Temperature">
            <dpt>9</dpt>
            <parameter id="1">
                <param-description>Temperature Transmit Interval in seconds</param-description>
                <param-type>uint16</param-type>
                <min>5</min>
                <max>3600</max>
            </parameter>
            <parameter id="2">
                <param-description>Temperature offset</param-description>
                <param-type>int16</param-type>
                <min>-5</min>
                <max>5</max>
                <factor>100</factor> <!-- Umrechnung von eingegebenem zu übertragenem Wert -->
            </parameter>
        </object>
         <object id="20" name="Humidity">
            <dpt>9</dpt>
            <parameter id="1">
                <param-description>Humidity Transmit Interval in seconds</param-description>
                <param-type>uint16</param-type>
                <min>5</min>
                <max>3600</max>
            </parameter>
        </object>
    </objects>
</device-config>

Auch hier: Kommentare willkommen.

**l0wside** · 26.02.2014, 22:46

Zitat von greentux Beitrag anzeigen

Wären ja vl. auch nur verschiedene Backends.
Man könnte via Bus (in welcher Form auch immer), man könnte via SD-Card, oder oder.

Danke für den Hinweis. Wir haben hier zwei Diskussionen parallel:

Wie kommen die Daten zum Gerät?
Wie werden die Daten im Gerät abgelegt?

Ich habe mich nur mit #1 beschäftigt. dreamy1 wäre vermutlich eher an #2 gelegen. Und ja, ich will meine Geräte über den Bus konfigurieren können. Für eine SD-Karte hätte ich gar keinen Platz...

Max

**dreamy1** · 26.02.2014, 22:55

Puuh,

ich glaube da klinke ich mich aus, die Flughöhe ist mir zu weit weg. Vielleicht haben wir da eben auch unterschiedliche Ansätze: ich möchte mich bei einer nachbaubaren Low-End-Bastelversion für "Dummies" nicht um Subsets, Properties und Indizes oder sonstige Dinge kümmern und mich da langwierig einlesen müssen, um annähernd zu verstehen was da jetzt genau wo stehen muss.

Da seid Ihr als µC-Profis sicher effizienter. Vielleicht entsteht ja am Ende eine "Basis", die man mit Synergie nutzen kann.

Ich denke der Bedarf nach DIY-Geräten ist riesig, aber die wenigsten Interessenten wollen so tief ins notwendige Detailwissen gehen, um am Ende lauffähige Geräte am Bus zu haben.

**dreamy1** · 26.02.2014, 23:09

Eine Grundsatzfrage, die sich aufdrängt:

Sollen die Geräte später von jedermann nachgebaut werden können, auch ohne tieferes Detailwissen zu KNX-Protokollen und deren Aufbau?

Falls nicht, werden wir hier sicher sehr professionell softwaredesignte Geräte sehen, die jedoch nur von den (wenigen) Urhebern selbst gebaut und verstanden werden können. Ich würde behaupten, dass 95% der User hier mit den obenstehenden Posts nur Bahnhof verstehen (mich eingeschlossen :-) ).

**Robert** · 27.02.2014, 00:15

@Max:

Vorweg: Ich denke die BCU2-Kompatiblität sollte man schon gewährleisten. Die BCU2 ist ja keine Idee von Martin Kögler sondern der EIBA/Siemens. Daher ist auch in der ETs ein Mindestmaß an Unterstützung vorhanden.

Stand bei mir momentan:

BCU2-Gerät (z.B. Merten Busankoppler) in der ETS
- PA proggen - der Startpunkt sollte immer funktionieren
- Geräteinfo abfragen (wichtig!) - hier können wir wie von dir vorgeschlagen etvl. über ein Nummernschema bei den Seriennummern auch unsere Geräte erkennen, zudem ist der Runstate erkennbar ohne Kommandozeile/Spezialtools
- Reset ("zurücksetzen")
- damit ist das Gerät sichtbar und man kann ggfl. ein paar (Fake-)GAs für die Nutzung mit Linienkopplern zuweisen
eibd-Unterstützung:
- addresswrite sollte korrekt funktionieren
- xpropwrite/xpropread
- mreset (zum Zurücksetzen nach der Programmierung)
- progmodestatus,-on,-off,-toggle - das bedingt, dass der "SystemState" dynamisch und nicht nur read-only ist! Angenehm: hier speicher ich auch eine Reset-Anforderung (Flag "DM") und eben den Prog-Button. Dann funktioniert eben dessen Anzeige unter "Geräteinfo" auch korrekt.
Die Unterschiede der Konzepte für die KO-Parameter sind recht marginal, bei mir momentan
- KO 10:
  - jedes Property: GA [2 Byte] + KO [1 Byte]
  - Vorteil: 256 GAs möglich
- KO 11:
  - jedes Property ist ein KO: Flags + variable Parameter
  - in der Firmware ist festgelegt, wie lange die Variablen Parameter sind, so dass im EEPROM alles hintereinander geschrieben steht.
dein Konzept sieht auch sehr gut aus, müsste ich drüber nachdenken - dein XML sieht nämlich gut aus.
- ein mögliches Problem: Die Anzahl der GAs pro KO ist bei dir variabel pro KO - dadurch musst du wenn du die Struktur serialisierst ja eine Mindestanzahl frei lassen (scheint bei dir 8 zu sein!?) die evtl. nie genutzt wird - könnte man natürlich auch nicht machen, aber dann müsstest du den gesamten nachfolgenden EEPROM-Inhalt beim Hinzufügen einer GA umkopieren?
- In meiner Firmware lege ich momentan die Maximallänge eines Property fest und prüfe bei einem Schreibvorgang dies ab (Start+Länge) < max_Länge - bei deiner Version müsste man dass ggfl. für jedes der Properties eines KOs machen wenn man sich nicht auf das XML verlassen will?

Vielleicht kann man sich auf jeden Fall auf die Unterstützung der o.g. Funktionen in ETS und eibd verständigen. Flag-Reihenfolge sicher auch. Bei GA->KO wäre natürlich ein entsprechendes Tuple schön damit das Zusammenhängend geschrieben und gelesen werden kann. Die eigentlichen Parameter wiederum könnte man doch tatsächlich mit kompletten Koordinaten Object-Property-Start definiert werden und wären dann völlig unkritisch.

So schreibe ich momentan die Parameter der Steuerung eines Garagentors:

Code:

#!/bin/bash

EIB_URL=local:/tmp/eib
PA=1.1.210

ADDR_TABLE_OBJ=10
KO_TABLE_OBJ=11

OBJ_DEVICE=0
OBJ_OPEN_CLOSE=$[$OBJ_DEVICE+1]
OBJ_STOP=$[$OBJ_OPEN_CLOSE+1]
OBJ_LIGHT=$[$OBJ_STOP+1]
OBJ_VENT=$[$OBJ_LIGHT+1]
OBJ_DRIVE_LOCK=$[$OBJ_VENT+1]
OBJ_KNX_LOCK=$[$OBJ_DRIVE_LOCK+1]
OBJ_STATUS_OPEN=$[$OBJ_KNX_LOCK+1]
OBJ_STATUS_CLOSED=$[$OBJ_STATUS_OPEN+1]
OBJ_STATUS_MOVING=$[$OBJ_STATUS_CLOSED+1]
OBJ_STATUS_VENT=$[$OBJ_STATUS_MOVING+1]
OBJ_STATUS_ERROR=$[$OBJ_STATUS_VENT+1]

FLAG_COMMUNICATE=$[1<<0]
FLAG_READ=$[1<<1]
FLAG_WRITE=$[1<<2]
FLAG_TRANSMIT=$[1<<3]
FLAG_UPDATE=$[1<<5]
FLAG_READ_ON_INIT=$[1<<6]

echo "writing PA"
#xpropwrite $EIB_URL 1.1.240 $ADDR_TABLE_OBJ 0 0 3 11 d2 00
writeaddress $EIB_URL $PA

echo "writing GAs"
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  1 0 3 00 64 `printf '%x' $OBJ_OPEN_CLOSE`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  2 0 3 00 65 `printf '%x' $OBJ_STOP`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  3 0 3 00 66 `printf '%x' $OBJ_LIGHT`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  4 0 3 00 67 `printf '%x' $OBJ_VENT`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  5 0 3 00 68 `printf '%x' $OBJ_DRIVE_LOCK`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  6 0 3 00 69 `printf '%x' $OBJ_KNX_LOCK`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  7 0 3 30 64 `printf '%x' $OBJ_STATUS_OPEN`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  8 0 3 30 65 `printf '%x' $OBJ_STATUS_CLOSED`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ  9 0 3 30 66 `printf '%x' $OBJ_STATUS_MOVING`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ 10 0 3 30 67 `printf '%x' $OBJ_STATUS_VENT`
xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ 11 0 3 30 68 `printf '%x' $OBJ_STATUS_ERROR`

echo "writing KOs"
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_DEVICE         0 1 0
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_OPEN_CLOSE     0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_WRITE]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STOP           0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_WRITE]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_LIGHT          0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_WRITE]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_VENT           0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_WRITE]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_DRIVE_LOCK     0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_WRITE+$FLAG_READ_ON_INIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_KNX_LOCK       0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_WRITE+$FLAG_READ_ON_INIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STATUS_OPEN    0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_TRANSMIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STATUS_CLOSED  0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_TRANSMIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STATUS_MOVING  0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_TRANSMIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STATUS_VENT    0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_TRANSMIT]`
xpropwrite $EIB_URL $PA $KO_TABLE_OBJ $OBJ_STATUS_ERROR   0 1 `printf '%x' $[$FLAG_COMMUNICATE+$FLAG_READ+$FLAG_WRITE+$FLAG_TRANSMIT]`

echo "restarting device"
mrestart $EIB_URL $PA

@off-topic:

Ich sehe die "Arduino-Lösung für alle" eher im Bereich gebastelte Einzelstücke. Da kann man dann liebevoll die Parameter und GAs im "Sourcecode" ändern oder eine SD-Karte (sic!) einschieben - das will man aber nicht bei >10 Stück (Temp/Hum) machen oder bei Teilen die nicht direkt zugänglich sind (Garagentorantrieb, Wetterstation...). Wofür FatFS-Blähcode und SD-Karten Slot wenn ich dass ganze nach kurzer Denkpause remote vom PC erledigen kann?

"Selber löten" ist auch eine Illusion: Einzelstücke kann man ja gerne mit Siemens Interface bauen, hinterher wird man aber aus Platz- und Kostengründen sowieso eigene PCBs (nein, keine "Shields") fertigen.

Ich orakel, dass die schnellen Erfolge mit den Arduinos aus den oben genannten und noch mehr Gründen (v. a. Software-Performance und -flexibilität) recht schnell dort aufhören, wo man Stückzahl, Preis und Platzbedarf optimieren will.

Grüße
Robert

**tuxedo** · 27.02.2014, 09:43

Das XML Format sieht interessant aus. Aber ich würde mir hier was noch einfacheres wünschen.

Gerade in Hinsicht des KNX Arduino Sketch Skeletons wäre es doch für Anfänger hilfreich wenn die Konfigurationsfile so einfach wie möglich ist.

Leider bin ich bzgl. des Schreibens von Properties auf den Bus noch nicht durchgestiegen, so dass ich noch nicht abschätzen kann was da alles an Infos gebraucht wird und wie man das am einfachsten Aufbauen könnte.

Vielleicht kann mich hier jemand erhellen? Ein Link zu einer Art Doku/Howto wäre ein Anfang.

Die Idee mit der SD-Karte find ich nicht so doof. Ist eigtl. eine feine Sache. Aber das eine muss das andere ja nicht ausschließen. Wer den Overhead mit der SD Karte betreiben will: Kein Problem. Das Dateiformat kann ja das gleiche sein.

-----

Eine ganz andere Frage ist noch:

Wenn hier KNX Projekte von Anfängern nachgebaut werden: Dann wäre es doch hilfreich wenn es zum Projekt eine Projekt-Datei gibt (ähnlich zur de. .vd3/.vd4/.knxprod) die Beschreibt was das Gerät _kann_. Im Software-Tool wird dann basierend auf dieser Datei eine Eingabemaske angezeigt wo der Benutzer, ähnlich wie in der ETS, seine Einstellung vornehmen, und diese dann auf den Bus schieben kann.

Und in dem Zug wäre es nicht nur praktisch eine Datei zu haben die den Funktionsumfang beschreibt, sondern auch noch eine File die die aktuelle Konfiguration des Funktionsumfangs darstellt. So könnte man hilfesuchenden nicht nur sagen "stell hier das ein oder dort das", sondern "hier hast du eine konfiguration. probier mal die".

**l0wside** · 27.02.2014, 12:31

Zitat von Robert Beitrag anzeigen

"Selber löten" ist auch eine Illusion: Einzelstücke kann man ja gerne mit Siemens Interface bauen, hinterher wird man aber aus Platz- und Kostengründen sowieso eigene PCBs (nein, keine "Shields") fertigen.

Ich orakel, dass die schnellen Erfolge mit den Arduinos aus den oben genannten und noch mehr Gründen (v. a. Software-Performance und -flexibilität) recht schnell dort aufhören, wo man Stückzahl, Preis und Platzbedarf optimieren will.

Ich denke, dass es keine Einheitslösung geben wird. Einige haben ein einzelnes Detailproblem, das sich prima mit dem Arduino erschlagen lässt. Das ist eher ein Bastelansatz.
Andere wieder optimieren sich auf die von dir genannten Kriterien, das geht dann aber schon ganz schnell in den halbprofessionellen Bereich. Beides hat seine Berechtigung.
Ich würde gerne auch die Arduino-Fraktion mit einbeziehen, um zu einer einheitlichen Konfigurationsschnittstelle zu kommen. Auf Implementierungsseite kann es ja trotzdem unterschiedlich aussehen. Gefühlt müsste sich jemand Arduino-Kundiges bereit erklären, einen Beispielcode für den Arduino zu erstellen, der über eine einfache API zu bedienen ist. Freiwillige?

Max

**l0wside** · 27.02.2014, 12:49

Zitat von tuxedo Beitrag anzeigen

Leider bin ich bzgl. des Schreibens von Properties auf den Bus noch nicht durchgestiegen, so dass ich noch nicht abschätzen kann was da alles an Infos gebraucht wird und wie man das am einfachsten Aufbauen könnte.

Mein Einstiegsposting sollte eigentlich schon ein bisschen die Grundlagen erläutert haben. Praktisch schreiben kann man die Daten mit den eibd-Tools xpropwrite, lesen mit xpropread.
Beispiel (aus meinem Einstiegsposting): Object 20, Property 0, Index 2: 0x0B06. Das Gerät soll die PA 5.7.6 bekommen. Ablauf:

Gerät anschließen, Programmiertaster drücken. LED geht an.
Entweder:
- in der ETS neues (Dummy-)Gerät anlegen und von dort eine PA vergeben
- oder mit writeaddress [url] 5.7.6 die Adresse setzen.
PA ist nun gesetzt, die LED geht aus.
Property schreiben:
xpropwrite [url] 5.7.6 20 0 2 1 0B 06

Fertig!

Zitat von tuxedo Beitrag anzeigen

Wenn hier KNX Projekte von Anfängern nachgebaut werden: Dann wäre es doch hilfreich wenn es zum Projekt eine Projekt-Datei gibt (ähnlich zur de. .vd3/.vd4/.knxprod) die Beschreibt was das Gerät _kann_. Im Software-Tool wird dann basierend auf dieser Datei eine Eingabemaske angezeigt wo der Benutzer, ähnlich wie in der ETS, seine Einstellung vornehmen, und diese dann auf den Bus schieben kann.

Und in dem Zug wäre es nicht nur praktisch eine Datei zu haben die den Funktionsumfang beschreibt, sondern auch noch eine File die die aktuelle Konfiguration des Funktionsumfangs darstellt. So könnte man hilfesuchenden nicht nur sagen "stell hier das ein oder dort das", sondern "hier hast du eine konfiguration. probier mal die".

Dein Anwendungsfall leuchtet mir ein; ansonsten würde ich die Daten lieber nur einmal (d.h. in den Geräten) ablegen.
Machst du einen Vorschlag zur (optionalen) Erweiterung der XML-Datei? Alternativ tut es natürlich auch eine simple Liste Object/Property/Index/Value.

Max

**tuxedo** · 27.02.2014, 12:57

Zitat von l0wside Beitrag anzeigen

Ablauf:

Okay, jetzt ist es etwas klarer. Hatte versucht zu xpropwrite ein wenig Doku zu finden. Leider ohne erfolg.

Kurz und zusammenfassend gesagt: mit xpropwrite kann man auf eine beliebige PA Auf eine Objekt->Property->Index Struktur Werte schreiben?

Dein Anwendungsfall leuchtet mir ein; ansonsten würde ich die Daten lieber nur einmal (d.h. in den Geräten) ablegen.

Logo. Ins Gerät selbst muss es rein. Die ETS machts ja auch nicht anders. Nur mit dem Unterschied dass die Info noch in der ETS Datenbank gepsiechert bleibt. Da ist es nicht wirklich möglich mal eben die Konfiguration für ein Gerät zur wiederverwendung raus zu ziehen und irgendwo abzulegen.
Sehe hier im Forum ja immer die umständlichen Screenshots von Gerätekonfigurationen die man dann ggf. abtippen/manuell übernehmen muss.

Machst du einen Vorschlag zur (optionalen) Erweiterung der XML-Datei? Alternativ tut es natürlich auch eine simple Liste Object/Property/Index/Value.

Bevor ich mich da an einen Vorschlag wage muss ich erst den ganzen property-krempel richtig verstanden und verinnerlicht haben.

Würde aber mit meinem aktuellen wissensstand definitiv bei 2 Files bleiben: Eins für die Gerätebeschreibung (welche Objekte, Properties und Indizes gibts) und eins für die Werte. Beides zusammen ergibt dann von mir aus ein zusammengeführtes XML das mit dem Tool in das Gerät geschrieben werden kann.

**l0wside** · 27.02.2014, 20:55

Hallo Robert,

nun auch noch die inhaltliche Antwort, dafür brauche ich ein bisschen Ruhe.

Zitat von Robert Beitrag anzeigen

Vorweg: Ich denke die BCU2-Kompatiblität sollte man schon gewährleisten. Die BCU2 ist ja keine Idee von Martin Kögler sondern der EIBA/Siemens. Daher ist auch in der ETs ein Mindestmaß an Unterstützung vorhanden.

Kann man die BCU2 dann in der ETS einbinden? So habe ich dich jedenfalls verstanden. Das wäre natürlich dann ein starkes Argument dafür.

Zu deinen Punkten:

PA-Programmierung - klar notwendig
Geräteinfo. Ich würde eine nicht vergebene Herstellerkennung hernehmen, bei 16 bit gibt es genug Möglichkeiten. 0xAFFE, 0xBEEF, 0xDEAD, 0xFADE nur als ein paar Beispiele. Die Seriennummer kann jeder nach seinem Geschmack beschreiben.
Reset - meinetwegen, ich komme ohne aus, aber es spricht nichts gegen eine Unterstützung.
Runstate - dito.
SystemState - read-only von Busseite, wird aber natürlich vom Gerät jeweils auf den aktuellen Systemzustand angepasst.

ein mögliches Problem: Die Anzahl der GAs pro KO ist bei dir variabel pro KO - dadurch musst du wenn du die Struktur serialisierst ja eine Mindestanzahl frei lassen (scheint bei dir 8 zu sein!?) die evtl. nie genutzt wird - könnte man natürlich auch nicht machen, aber dann müsstest du den gesamten nachfolgenden EEPROM-Inhalt beim Hinzufügen einer GA umkopieren?

Habe ich noch nicht überlegt. Bei 2 Byte je GA denke ich darüber auch gar nicht so genau nach. Ich habe 384 Byte Flash zur Verfügung (mit einigen Kopfständen auch noch etwas mehr), da muss ich nicht übermäßig sparen. 3 KO mit je 8 möglichen Einträgen sind 48 Byte - so what?
Wie viel EEPROM haben Arduino und deine Lösung? Wenn du bei dir von EEPROM sprichst, ist vermutlich ein externes gemeint, d.h. Platz ohne Ende - richtig?
Mich treibt etwas anderes um. Ich finde zwar meinen Ansatz zum GA-Mapping stringenter als den Tabellenwust der BCU. Andererseits weiß ich nicht, welche Nachteile es hat, die
Das Backend könnte natürlich beide Ansätze parallel unterstützen und auf einen einzigen DAtensatz

In meiner Firmware lege ich momentan die Maximallänge eines Property fest und prüfe bei einem Schreibvorgang dies ab (Start+Länge) < max_Länge - bei deiner Version müsste man dass ggfl. für jedes der Properties eines KOs machen wenn man sich nicht auf das XML verlassen will?

Mache ich exakt genau so (auch beim Lesen). Indexabhängige Längen gibt es nur für Property 0 eines Objektes. Für Property 1...255 sind bei allen Indizes die Längen gleich. So jedenfalls lese ich den Standard.

Bei den Flags habe ich deine Definition bereits übernommen - dank #define ein Aufwand im Minutenbereich.

Die Gretchenfrage für mich ist nun: Kompatibilität zur BCU2 (mit allen Konsequenzen) oder eine eigene, aus meiner Sicht stringentere und logischere Implementierung. Was ist sinnvoller?

Max

Noch ein Punkt:

xpropwrite $EIB_URL $PA $ADDR_TABLE_OBJ 1 0 3 00 64 `printf '%x' $OBJ_OPEN_CLOSE`

Dazu eine Frage: du gibts no_of_elem bei deinem Mapping als 3 an. Ich verstehe das eher so, dass das ein einheitlicher Datensatz ist und hätte die Länge als 3 definiert (das lässt sich dann über PropertyDescription auslesen) und no_of_elem als 1 gesetzt.

Ankündigung

Konfiguration von DIY-Geräten

Konfiguration von DIY-Geräten

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar