Arduino Asksin library

[trilu]

@martin8573
ob das auf den neuen panstamps funktioniert kann ich dir nicht sagen - ich hab ja noch nicht einmal eine aktuelle :-)
nein, im ernst, wenn der cc1100 oder cc1101 drauf ist, dann wird es mit grösster wahrscheinlichkeit funktionieren. zumindest habe ich die lib so vorbereitet das der spi port und chip select einfach zu konfigurieren sind.

@martin876
das einstellen sollte ziemlich einfach sein, einmal möchte ich das über den programm code machen - also so:

Code Auswählen Erweitern

struct_hmConf hmConf;
void fillConf() {
hmConf.serID[0] =    'P','S','0','0','0','0','0','0','0','1'; // (10) serial ID, needed for pairing
hmConf.modID[0] =    0x80,0x01; // ( 2) model ID, describes HM hardware. we should use high values due to HM starts from 0
hmConf.subType[0] =  0x9F; // ( 1) not needed for FHEM, it's something like a group ID
hmConf.devInfo[0] =  0x01,0x01,0x01; // ( 3) describes device, not completely clear yet. includes amount of channels
hmConf.HMID[0] =     0xFF,0x00,0x01; // ( 3) very important, must be unique. identifier for the device in the network
hmConf.sendRetries = 3; // ( 1) how often a string should be send out until we get an answer
}

zum anderen haben die arduino's ja eine serielle schnittstelle und da möchte ich es auch konfigurierbar machen.
der freie speicher im eeprom ist beim avr328 nicht besonders üppig - er hat 1kb das wir nutzen können

ich könnte auch martin im quadrat antworten :-)

[martinp876]

avr328 nicht besonders üppig - er hat 1kb das wir nutzen können

Dann ist wohl eine der ersten Aufgaben, diesen zu optimieren.
Zum einen brauchst du platz für HMID und Serialnumber, FW version, model,... und zum 2. für die "Register".
Der erste Teil ist einfach, da du diesen einfach seqenzuell ablegen kannst. Wenn du nicht noch viel Addiert sollten so 50byte reichen.
Ich gehe davon aus, dass die Register zur Kompilezeit klar sind. Dann kann man eine Struktur über das EEPROM legen und somit den Speicher optimal nutzen.
Mal so ins Blaue den Bedarf (festgemacht an vorhandenen Devices):
List 0: 20Byte
List 1: 20Byte
List 3: 80Byte
= 1* list0 + 4* List1 + 4*10*List3 = 3,3kByte. Geht so nicht.

Wir stossen also schnell an Grenzen. Ich bin der Meinung, das für einen Schalter min 6 peers zugelassen werden müssen. Will man 4 Kanäle betreiben kommt man auf 24* List3. das sind dann max 40 Register....

Aus meiner sicht ergibt dies, dass keinerlei Platz für "dynamische" Zuweisungen ist.
Evtl kannst du mit diesen Konzept beginnen:
Nach start einfach einmal eine Anlernmessage schicken, die Daten dafür aus den EEPROM lesen. Danach regL_00 implementieren und sich von FHEM die HMID der Zentrale schicken lassen und speichern.

Gruss Martin

[trilu]

Du machst mich fertig mit diesen Registern, ich verstehe nur noch Bahnhof :-)
Lass es uns vielleicht mal an zwei Beispielen durchspielen, welche Register brauche ich pro Gerät und wie groß müssen die Register wirklich sein? Ich kann ja was anderes senden, als wirklich gespeichert wird....

1. Sensor Node mit 3 Temperatursensoren

2. 1 Channel Dimmer für Leds

[justme1968]

die register müssen doch nicht alle im ran oder eeprom liegen. alles was read only ist könnte doch z.b. auch in den flash speicher.

die daten eines panstamp wären diese hier:

Flash: 32 KB
RAM: 2 KB
EEPROM: 1 KB

die neuen panstamps werden 4kb ram haben.

gruss
  andre

[trilu]

Danke, das meinte ich mit - es muss ja nicht alles im eeprom liegen was gesendet wird :-)

[Dirk]

Wir stossen also schnell an Grenzen.

Daher haben einige HM-Devices einen externen Eeprom der per I2C angebunden ist.

Update:
z.B. den AT24C32 (2-Wire Serial EEPROM)
der hat 32 kb Speicher.

Gruß
Dirk

[martinp876]

nun, register sind User-Aenderbar und nicht flüchtig. Also EEPROM, von mir aus auch Flash. Welche Bänke hat das Flash? Halte ich als Option für unwahrscheinlich.
Alles was im Code ist ist kein "Register" mehr, da man es nicht aendern kann.

Welche Register zu Verfügung gestellt werden kann/muss man beim Bau der FW entscheiden. Das hält den Start des Projekts nicht auf. Ist aber gut, wenn man die Resourcen kennt. EEPROM ist im Vergleich zu HM devices nicht üppig, vorsicht hier.

Trotzdem - das wird ein elementarer Baustein der SW.
Stellt das "OS" auch timer zu Verfügung? Muss ich mir einmal ansehen, sonst kann ich nicht mitreden....

Gruss Martin

[betateilchen]

Ich würde auch grundsätzlich dazu tendieren, einen externen EEPROM Baustein zu verwenden.

[Dirk]

Hi Martin,

Code Auswählen Erweitern

Stellt das "OS" auch timer zu Verfügung?OS? Falls du den Mikrocontroller meinst, je nach AVR-Typ stehen unterschiedliche Timer zur Verfügung.

Ich würde auch grundsätzlich dazu tendieren, einen externen EEPROM Baustein zu verwenden.

Diese sollten sich auch einfach an einem Panstamp andocken lassen Und die gibt es auch als DIL-Versionen.

Gruß
Dirk

[betateilchen]

Jetzt hab ich in den Bastelkisten gewühlt und tatsächlich einen Arduino gefunden. Eigentlich müssten davon noch viel mehr da sein, komisch. Am Wochenende werde ich dann wohl das Funkmodul verdrahten (heute hab ich dazu keine Lust mehr) und dann bin ich beim Testen auch mit dabei.

[martinp876]

Hi Dirk,

ok, OS ist hoch gegriffen - aber ein paar system funktionen und ein dispacher ist vorhanden? Hilft nichts, ich muss lesen.

Für einfache Anwendungen sollten wir schon versuchen mit boardmitteln auszukommen. Ein externes EEPROM sollte nicht zum minimal System gehören. Es wäre ein add-on wenn die boardmittel nicht reichen.
Die "Platfom" darf dies nicht fordern, sollte es aber unterstützen.

Gruss Martin

[trilu]

so, und wieder mal ein update...

senden müsste jetzt auch gehen, dazu einfach in der seriellen console einen string in folgendem format mit carriage return absenden:
$0B $7F $A2 $40 $1F $A6 $5C $63 $19 $63 $01 $A2 <cr>

der string kommt dann in einen buffer und wird einmal versendet.
ACK handling ist vorbereitet, aber noch nicht implementiert.
testet mal bitte ob das so funktioniert.

ich bräuchte noch eine möglichkeit mir die empfangenen strings in fhem anzeigen zu lassen. am besten über eine telnet session.
ich nutze den HM USB Adapter und den hmland treiber.

[martinp876]

mache doch einfache eine telnetsession in auf dein System auf. Dann ein tail -f <syslogfile> und du siehst alle logs live.

Und nun "weg mit den Mist" (nicht ernst nehmen...)
in FHEM
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

Du solltest alles sehen, was HM formatiert kommt.

Klar: FHEM muss laufen ;-)

Gruss Martin

[betateilchen]

Am Wochenende werde ich dann wohl das Funkmodul verdrahten (heute hab ich dazu keine Lust mehr) und dann bin ich beim Testen auch mit dabei.

so... fertig gebastelt:

(http://up.picr.de/15442607cn.jpg)

und scheint auch zu funktionieren:

Code Auswählen Erweitern


start AskSin sketch
SPI_init done
cc1100_init: 123.....................4 done

Available commands:
  b,b,b i       - set device ID (3 bytes)
  b[0],b[n] s   - send a string, b[0] is length (50 bytes max)
  n/a           - load configuration from EEPROM
  n/a           - write configuration to EEPROM

 $nn for HEX input (e.g. $AB,$AC )


Jetzt muss ich mich noch hier durch den Thread wühlen um rauszufinden, wie das Ding jetzt genutzt wird.
Empfangen tut es schonmal fleißig. NSA hat grade den "I like it" Button geklickt  :O)

[betateilchen]

ich blick da grade nicht mehr durch.

Könnte man mal zusammenfassen, was bisher funktionieren sollte?

Das Setzen einer Adresse mit i habe ich kapiert

Wie könnte man eine Temperaturnachricht (wie z.B. vom HM-WDS10-TH-O kommend) byteweise zusammenstellen und (to broadcast) senden, um die dann in fhem irgendwo auftauchen zu sehen?