Arduino Asksin library

[Dirk]

@betateilchen,

hattest du eigentlich mal ein Feedback von ELV bekommen wegen der TRX1 Module?

Gruß
Dirk

[martinp876]

Das Pairing funktioniert grundsätzlich, wird aber noch nicht gespeichert.

Wenn ich es recht verstehe antwortet der PS auf die pairing message von FHEM und filtert die HMID heraus.
das Speichern und Nutzen der ID ist das eigentliche pairen. Und noch das Rücklesen der Register.

Habt ihr eine schon Idee zu Sequenznummer und HMID des PS?

Gruss Martin

[betateilchen]

hattest du eigentlich mal ein Feedback von ELV bekommen wegen der TRX1 Module?

Ja...

Das Sende-/Empfangsmodul führen wir einzeln nicht in unserem Liefersortiment. Wir werden Ihnen in diesem Fall im Rahmen der Kulanz aus unserer Retourenware ein Sende-/Empfangsmodul kostenlos zusenden.

Wir hoffen, Ihnen hiermit geholfen zu haben.

[betateilchen]

Habt ihr eine schon Idee zu Sequenznummer und HMID des PS?

Falls Du mit Sequenznummer die Seriennummer meinst, dann blättere einfach mal ein Stück hier im Thread zurück. Dort hatte ich einen Vorschlag zu S/N und HMID gemacht und es wurde geantwortet dass man sich darum derzeit noch keine Gedanken machen müsse...

[trilu]

War ein paar Tage im Urlaub :-)))

Mal wieder ein kleines Update, hab die lib komplett überarbeitet, da ich mich nicht mehr wirklich zurecht gefunden habe...
Basiert jetzt auf einer Class. Schaut es euch einfach selbst an.

@martin - schön das du wieder da bist!

Habt ihr eine schon Idee zu Sequenznummer und HMID des PS?

Derzeit vergebe ich das im Flash. Wird also beim Programmieren gesetzt - also hier:

Code Auswählen Erweitern

const unsigned char HM_settings[] PROGMEM = {
'P','S','0','0','0','0','0','0','0','1', // hm.C.serID[10]    serial ID, needed for pairing
0x80,0x02, // hm.C.modID[2]     model ID, describes HM hardware. we should use high values due to HM starts from 0
0x9F, // hm.C.subType[1]   not needed for FHEM, it's something like a group ID
0x04,0x01,0x01, // hm.C.devInfo[3]   describes device, not completely clear yet. includes amount of channels
0x3F,0xA6,0x5C, // hm.C.HMID[3]      very important, must be unique. identifier for the device in the network
3, // hm.C.sendRetries  how often a string should be send out until we get an answer
0xF4,0x01, // hm.C.timeOut      needs two byte split; time out for ack handling
};
Die HMID kann man auch per serieller Konsole ändern, wird aber derzeit nicht gespeichert.
Ich denke das sollte für den Anfang so gehen, komplett dynamisch wird der Sketch wohl nicht werden, weil schliesslich muss ja auch noch Funktionalität zu den Registern programmiert werden.

Pairen geht derzeit von:

Code Auswählen Erweitern

<- 1A 00 84 00 3F A6 5C 00 00 00 0A 80 02 50 53 30 30 30 30 30 30 30 31 9F 04 01 01 (l:27) <- SE (3614) 1
-> 10 01 A0 01 63 19 63 3F A6 5C 00 05 00 00 00 00 00 (l:17)(4159)
   start config mode
<- 0A 01 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (4171) 1
-> 13 02 A0 01 63 19 63 3F A6 5C 00 08 02 01 0A 63 0B 19 0C 63 (l:20)(5089)
   new PairID: 63 19 63 (l:3)
<- 0A 02 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (5101) 1
-> 0B 03 A0 01 63 19 63 3F A6 5C 00 06 (l:12)(5750)
   config end
<- 0A 03 80 02 3F A6 5C 63 19 63 00 (l:11) <- SE (5758) 1

An den Registern bin ich gerade dran...
Eine Verständnisfrage dazu hätte ich - per 04 werden die Register einzeln abgefragt - also
00 für Device - mit einem Inhalt wie 02:01 0A:63 0B:19 0C:63
01 für Channel 01?
02 für Channel 02?
Ich bekomme das mit den Registern oder Channels noch nicht gebacken. Ist Register oder Channel die führende Struktur?
also sowas wie:

Device:
- Channel 00
- Channel 01
- Channel 02

Kanal 1
- Channel 00
- Channel 01
- Channel 02

usw.?

Zweite Frage, ich sehe in den Registern sowas als Inhalt
02:01 0A:63 0B:19 0C:63
30:06 32:50 34:4B 35:50 56:00 57:24 58:01 59:01 00:00

Sind das Adressen vor den Werten? 0A, 0B, 0C - Byte Adresse mit folgendem Inhalt 63 19 63 ?

Code Auswählen Erweitern


                                    Channel     PEER Addr  PEER  Param List
l> 10 04 A0 01  63 19 63  1E 7A AD  01      04  00 00 00   00    01 (l:17)(131270)


Slave sendet param liste an Master
  "10;p01=02"   => { txt => "INFO_PARAM_RESPONSE_PAIRS", params => {
                     DATA => "2,", },},
                              RegL_01:  30:06 32:50 34:4B 35:50 56:00 57:24 58:01 59:01 00:00
l> 1A 04 A0 10  1E 7A AD  63 19 63  02  30 06 32 50 34 4B 35 50 56 00 57 24 58 01 59 01 (l:27)(131405)


[martinp876]

Hi,

register:
kann man byteweise setzen
kann man nur in Blöcken abfragen, also eine komplette liste oder liste/peer
können in manchen devices 'lokal' geaendert werden - dann sendet das Device die Aenderung "einzeln" an die Zentrale (z.B. TC)

ein Registerblock hat einen Adressbereich von 1 bis 255. Nicht alle Addressen werden genutzt - es werden immer nur die genutzten gesendet.

hier ein Beispiel
01 04 1BCCB802 03 # anfrage der Zentrale: schicke Register Channel 1/Liste3/peer 1BCCB802
das Device entscheidet das format '03' also Blöcke zu verwenden
03 01 000000326400FF00FF011112680000 # Block ab addresse 01, also 01 bis 0x10
03 11 C80000000000000000000000FF6800 # Block ab addresse 01, also 01 bis 0x10
03 81 000000326400FF00FF211112680000 # Block ab addresse 01, also 01 bis 0x10
03 91 C80000000000000000000000046800 # Block ab addresse 01, also 01 bis 0x10
03 00 00 #Adresse 00 - das bedeutet "Ende der Sequenz" das muss immer am schluss stehen!

Alternativ könnte das device mit format "02" antworten:
00 04 00000000 00 # anfrage der Zentrale: schicke Register Channel 0/Liste0/peer 00000000
# channel 0 ist das Device, also kein channel. Bei list 0 gibt es keine peers,als wird peer aof 00000000 gesetzt
02 0281 0A17 0B43 0CBF 15FF  # 02 ist das Format, die 4er gruppen ist jeweils Adresse/data
03 0000 # hier wurde format 03 zum Terminieren gewählt.

Alternativ könnte das Device auch
02 0281 0A17 0B43 0CBF 15FF 0000
senden. Die 0000 am Ende terminiert auch die Serie.
=> Register Sequenz wird IMMER mir addr:00 data:00 terminiert, format 02 oder03 ist hier bei egal

Gruss Martin

[betateilchen]

Wenn das in dem Beispiel wirklich 4 Mal "# Block ab addresse 01" heißt, verstehe ich die Logik nicht.

[trilu]

so langsam beginne ich zu verstehen wie die dinger funktionieren....
d.h. das device legt fest welche variablen es an welchen adressen hat, also von HM festgelegt.

nachdem der eeprom des avr 328 begrenzt ist, sollten wir uns eine generelle struktur überlegen. die variablen und damit verfügbaren adressen können wir ja dann als standard für eigenbau devices verwenden.

willst du dir mal gedanken machen wieviele register wir anlegen mit wieviel platz pro register. wir haben beim panstamp 512 byte zur verfügung.
L01 braucht adresse 02, 0A, 0B und 0C also 4 byte weg.

was denkst du, macht das sinn?

[Dirk]

nachdem der eeprom des avr 328 begrenzt ist

Daher würde ich für umfangreichere Aufgaben die Nutzung eines externen EEprom vorsehen. Dieser ist sehr einfach anzuschließen und kostet nur ein paar Cent.

Gruß
Dirk

[trilu]

darüber habe ich auch nachgedacht, aber unser panstamp ist ja nicht allein auf der welt.
ziel der aktion ist ja, hardware für unsere HM installation bauen zu können, die es so nicht zu kaufen gibt.
d.h. selbst wenn wir hier mehr als 512 byte an variablen ablegen können, so muss ja FHEM auch wissen, was mit den variablen anzufangen ist.

deshalb die idee, wir legen ~10 default devices in der schnittstelle zu FHEM und in der Asksin library und verwenden die Register nach unseren vorstellungen....

[betateilchen]

Ich bin auch dafür, den begrenzten internen EEPROM Speicher einfach zu ignorieren und generell einen externen Speicher zu verwenden.
Zuviel Speicher kann man nicht haben. Mit 512 Byte kommt man wirklich nicht weit, und beim Arduino siehts auch nicht viel besser aus.

Von Begrenzungen des Funktionsumfangs bereits im Vorfeld halte ich gar nichts.

[martinp876]

Hi,

sorry, ist nicht immer Adresse 01 sonder 0x01-0x10, 0x11-0x20 0x81-0x90 und 0x91-0xA0

wir muessen unterscheiden zwischen der Darstellung in den Messages und der Speicherung im EEPROM.
Mein Vorschlag mir den Strukturen waere sicher nicht der Weg, wie ich es implementiere. Ich bin gegen ein Standart-zusatz-EEPROM, jedenfalls nicht weil die Register so viel Platz brauchen. Der Mechanismuss sollte ein zusatzprom zulassen. Mit etwas coding lässt es sich deutlich einfacher schaffen.
Ich bastle mal einen "sinnvollen" Vorschlag...

Soweit, denke ich, sind wir uns von der Architektur einig (ganz grobe Darstellung!!)

modul EEPROM
- verwaltet den physikalischen Addressraum
- stellt ein API zu Verfügung zum Schreiben
- ist skalierbar so dass auch ein zusatzEEPROM verwaltet wird - der virtuelle Addressraum wird linear.

modul register
- Sinn des Moduls ist es requests aus den Messages auf das EEPROM zu mappen
- macht die Umrechnung der Message-Addressierung (chan/list/peer/addr) nach virtuellen EEPROM addressraum
- stellt get und set funktionen zu verfügung, evtl getBulk, getall,... geschmackssache.
- set bedient das schreiben
- die get funktion könnte die Daten passend für die Message aufbereiten
- muss auch messages wie "fertig zum Schreiben" und "schreiben beendet" bedienen.
- auch die Peer-IDs müssen berücksichtigt werden!

Modul fData
- stellt ein API für die Operational SW auf das EEPROM dar.
- Die Register sind ja Daten, die für den Betrieb genutzt werden müssen. Daher muss auf die Daten immer schnell zugegriffen werden können.
- Mein Vorschlag ist, einfach eine Struktur über die Bereich des Proms zu legen, pointer basiered. Die Organisation hier ist nach Funktion zu organisieren, also statemachine, paired To


Für den Quickstart wollen wir das pairen konnen. Hierzu brauchen wir nur List 0, channel 0.
Somit konnen wir erst einmal speicher fressen, das wird dann später korrigiert, in den beiden Modulen.

Im EEPROM nutzen wir 255 Bytes
register muss chn/list/peer/addr (jetzt nur 0/0/0/addr) auflösen in
chars [1][1][1][255]
peering würde dann auf Adresse 10/11/12 schreiben oder 9/10/11 im EEPROM (HM fängt nicht bei 0 an)

Wenn eine read message kommt müssten dann "alle" bytes gesendet werden - zum Testen auch gerne 255
register liefert dann z.B. ein Array mit
01 000000000000000000PAIRID000000
11 000000000000000000000000000000
21 000000000000000000000000000000
...
D1 000000000000000000000000000000
E1 000000000000000000000000000000
F1 0000000000000000000000000000

der messageparser muss dann das Array in messages packen und das Terminieren einbauen (0000)

Ist ein schöner test, dass das Generieren der Messages funktioniert.

Ein Inteligenter Vorschlag zur Speicherverwaltung kommt noch.Das muss erheblich gestrafft werden, klar

So wieder viel gefaselt - kann man es verstehen, ist dieArchitektur so akzeptabel?


Gruss Martin

[Dirk]

Ich bin auch dafür, den begrenzten internen EEPROM Speicher einfach zu ignorieren und generell einen externen Speicher zu verwenden.

Von Ignorieren hab ich gar nicht geredet. Es gibt sicher viele Anwendungsfälle wo der interne EEprom ausreichend ist. Wir sollten aber einen optionalen externen EEprom vorsehen.

Gruß
Dirk

[martinp876]

@Dirk,

absolut deiner Meinung - ich denke betateilchen wollte IMMER externe PROMS. Egal, kein Fingerpointing.

Ich versuche ein Konzept zu erarbeiten, dass eine Struktur für das "reading" und das variablenmodul erstellt.
Ich denke an einen code-generator, man gibt die Register in einer Tabelle an und erzeugt die C-files mit den Datenstrukturen. Schreiben ich evtl in Perl.

Man erstellt also die Register-definition im Textfile. Dann generiert man die C-files und kopiert sie in das ASKIN file (oder included sie).

Wenn man ein neues PS modul bauen will aendert man die Definition und kompiliert neu. Natürlich muss man die Nutzung der Register noch programmieren, eben die Spezielle Funktion der Register.

Das pre-Perl script kann dann auch einen Output erstellen, den man mit regList vergleichen kann.
Mal sehen, heute aber nicht mehr... ;-)

Gruss Martin

[herrmannj]

könnt ihr bitte aufhören so geile Ideen umzusetzen ? Irgendwann wirds zu teuer (sagt meine Frau ... ;-)

Kann mir jemand Tips zur Bestellung geben, bitte ?

a: auf der Frontseite haben die einen Prototypen für V2. Soweit ich sehe mehr Speicher und AES, dafür keine Header... lohnt es sich zu warten ?

wenn nein oder vielleicht:

einzige Quelle ist der store unter panstamp.com ? im Augenblick scheint da fast alles out-of-stock zu sein, liegt wohl an den ferien ... Versand ca 10$ ?


Passt das so oder gibt es sinnvolle Ergänzungen (hab ich was vergessen was ich hinterher bereue ?)
* panstick developer board ?
* DHT11 oder DHT22 (lohnt sich DHT22)?
* Gehäuse ? (Kann man die nehmen oder sehen die in echt total hässlich aus ? Bleibt noch ein wenig Platz für anderen Sensoren frei ?)
* Output Board ?
* rgb Board ?
* lohnt sich eine externe Antenne ?

Danke für Tips, Grüße
Jörg