Status einer Alarmanlage per Panstamp?

[Tobias]

Hi Andre,
ich mal mal ein neues Thema dafür auf ;)

Und zwar möchte ich per Funk und Batterieversorgung den Status meiner Alarmanlage über LowCurrentLED's anzeigen. Die sollen aber nicht dauerleuchten sondern nur alle 30sek aufblinken.
Kann ich dafür als Basis den Binouts Sketch verwenden? Kann den schon dein Modul? Wie muss ich welche Register ansprechen um die 8 Digitalen Ports an oder abzuschalten?

Das Aufblitzen müsste ich dann noch irgendwie in die mainloop einbauen, ausgehend vom Status der jeweiligen Register:

Code Auswählen Erweitern

void loop()
{
byte dtBinOutputs[1];       // 8 Binary output states
REGISTER regBinOutputs(dtBinOutputs, sizeof(dtBinOutputs), NULL, &setBinOutputs);

byte i;
// Control pins
  for(i=0 ; i<sizeof(binaryPin) ; i++)
    digitalWrite(binaryPin[i], (dtBinOutputs[0] >> i) & 0x01);

  delay(400);
 
  for(i=0 ; i<sizeof(binaryPin) ; i++)
    digitalWrite(binaryPin[i], LOW);
 
  delay(4900);
}
Ich verstehe noch nicht wie ich die einzelnen Register auslesen kann. Ich muss wissen, ob TRUE oder FALSE drin steht. Macht das der REGISTER befehl?
Was meinst du? Machbar? Vor allem die Batterieverorgung? Schließlich muss der Panstamp permanent am Funk lauschen um ohne Zeitverzögerung Befehle entgegen nehmen zu können und die Ports zu schalten...

[justme1968]

wenn du einen bestehenden sketch verwenden möchtest kannst du auf binouts oder binouts2 aufsetzen.

der unterschied ist das bei binouts ein register für alle ausgänge verwendet in dem jedem ausgang ein bit zugeordnet ist. man muss also auf sender seite bits manipulieren und immer den status aller ausgänge auf ein mal übertragen.

binouts2 hat pro ausgang ein register und man setzt einfach ein komplettes register unabhängig von den anderen ausgängen.

je nach dem wie oft sich die ausgänge änern hätte binouts den vorteil das nur eine nachricht für alle register benötogt wird und weniger funkverkehr und batterielast anfällt.

mein modul müsste mit beiden klar kommen. wenn nicht liegt der fehler bei mir :)

unabhängig davon welchen sketch du verwendest würde ich versuchen so viel und so oft wie möglich das funkmodul und auch den aruino schlafen zu legen. wie oft und wie lange das geht hängt von deinen genauen anforderungen ab:

- was genau ist ohne zeitverzögerung wenn die led nur alle 30 sekunden blinken?
- ist vielleicht doch ein kleiner delay erlaubt?
- sollen die 8 leds synchron blinken? (wenn nein schaut das vermutlich sehr chaotisch aus, wenn ja wie soll das sofort reagieren dann aussehen?)
- man müsste mal genau durchrechnen wie viel ein panstamp in den unterschiedlichen betriebsarten zuzüglich der leds braucht. ich vermute mal eine dickere batterie wäre unter umständen hilfreich.

REGISTER ist kein befehl sondern eine c++ klasse. die kapselt das senden und empfangen der swap register. der zu jedem port gehörende wert ist ein bit in der variablen dtBinOutputs. die erste schleife geht über alle bits und setzt den ausgang wenn das bit 1.

machbar ist das ganz sicher. ich kann nur nicht einschätzen welche batterie grösse welche laufzeit hat und wie sehr man aufs stromspaaren achten muss. der unterschied zwischen schlafend (1uA) und senden (20mA) sind immerhin 4 größenordnungen.

gruss
  andre

[Tobias]

Hi Andre,
danke für die Info... Ich habe zuerstmal binouts auf den panstamp gebrannt, scheitere aber schon am "set SWAP_F0 setReg ????" Zb. "regSet 0B 11111111" um alle Ausgänge anzuschalten klappt nicht ;)
Ich kann alle LEDs auf einmal setzen, es reicht also binouts.
Schlussendlich sollen alle geschalteten Register die jeweilige LED gleichzeitig aufblinken lassen. Sonst wärs chaos ;)

Mit Zeitverzögerung meine ich, wenn ich das Register setze, sollen alle LEDs für 2sek dauerleuchten um den neuen Status anzuzeigen. Danach soll der Status alle 30sek für 400ms angezeigt werden.
Ich denke es ist wichtig, das bei Betätigung der Taste(egal welche) sofort der setReg Befehl zum Panstamp gesendet wird und dieser ihn auch sofort umsetzt. Der WAF würde darunter leiden wenn eine gefühlte Verzögerung von über 1sek da wäre.

Es sollte auch kein Problem sein eine A-Batterie 1.5V (diese Mega-dicken fetten) statt der AA anzuschließen

Edit: Hab gerade gesehen: die Übetragung der Batteriespannung ist da noch nicht drin, muss ich noch mit einbauen

[justme1968]

bei den low level befehlen wie regSet geht immer alles in hex. das registert ist glaube ich mit einen byte länge definiert. um alles einzuschalten also 'set SWAP_XX regSet 0B FF'.

ich kann nicht einschätzen ob z.b. eine halbe sekunde verzögerung schon so viel batterie sparen würde das es sich eventuell schon lohnt. selbst mit den 8mhz läuft er sonst viele 1000 male unnötig durch die loop ohne was zu tun.

für die batteriespannung kopier dir am  besten alles was mit REGI_VOLTSUPPLY zu tun hat aus regtable.h und regtable.ino aus soilmoisture in das entsprechende file des binouts sketch. am besten legst du dir dafür eine kopie an. um die original version und die mit dem zusätzlichen register zu unterscheiden wäre es gut dem ding einen eigenen product code zu geben. sonst weiss das fhem modul nichts vom voltage register. wenn du dir keine developer id besorgen möchtest (das kostet nur eine e-mail) kannst du meine verwenden. du musst dir dann einen namen für dein modul ausdenken und es in .../FHEM/lib/SWAP/devices.xml eintragen. dann im gleichen verzeichniss das panStamp/binouts.xml nach justme kopieren und da die id anpassen und das zusätzliche register eintragen.

wenn du es am laufen hast schick es mir und ich checke ich es ein damit es nicht beim nächsten fhem update überschrieben wird.

wenn du nicht damit klar kommst kann ich das auch schnell machen.

gruss
  andre

[Tobias]

klappt leider nicht...

Code Auswählen Erweitern

set SWAP_F0 regSet 0B FF
value has to be 0.1 byte(s) in size

Wobei ein "0C FF" angenommen wird. Allerdings wird zwar der ReadingsTimestamp aktualisiert, aber bei den PWM´s bleibt trotzdem alles auf 00 stehen. Ich hätte erwartet das alle 4 REadings sich auf FF ändern

[justme1968]

du hast recht. ich hatte bei den endpoints (teile eines registers) auf byte ebene aufgehört. und dann statt dessen den binouts2 sketch verwendet. ich schaue mir das noch mal an.

gruss
  andre

edit: ich hab gefunden warum es nicht geht: zum einen gibt es im device description file kein register für alle bits gemeinsam sondern nur für die einzelnen endpoints. nimm mal bitte das angehängte file und kopiere es nach .../FHEM/lib/SWAP/panStamp. danach ein 'set <device> readDeviceXML' beim 'get <device> regList' sollten dann zwei neue register auftauchen: 0B für die binary outputs und 0C für die pwm outputs. das erste ist 1 byte gross das zweite 4. 0B solltest du dann wie oben beschrieben direkt setzen können. 0C entsprechend. wenn es einen wert in 0C gibt solltest du danach auch 0C.1 bis 0C.4 für die 4 einzelnen pins setzen können.

das setzten der einzelnen bits mit 0B.x geht damit aber noch nicht.das muss ich tatsächlich noch einbauen.

[justme1968]

ich habe eben eine neue version eingecheckt bei der auch endpoints mit nur einem bit gehen. damit sollte dan auch ein regSet 0B.x gehen.

das xml file oben war das für den falschen sketch. ich habe das richtige mit eingecheckt.

gruss
  andre

[Tobias]

Hi Andre,
komm heute abend wieder dazu.
Ich arbeite aber z.Z. mit binouts und nicht mit bininps ;)

[justme1968]

deswegen sag ich das file war falsch :)

eingecheckt ist das richtige binouts.xml.

gruss
  andre

[Tobias]

warscheinlich stell ich mich zu blöde an.. Das xml habe ich kopiert und neu eingelesen.

set SWAP_F0 regSet 0B FF

funktioniert, jedenfalls keine Fehlermeldung. Die Readings ändern sich nicht.

Erst mit einem
set SWAP_F0 regGet 0B

gibts das Reading "0B-Binary_outputs    FF"
Alle anderen Readings bleiben leer.

set SWAP_F0 regSet 0B.0 FF
wird zwar abgesetzt, an den Readings (auch nach einem regGet) änden sich nicht.

Ich kann am Board noch nicht den Status der Ports überprüfen. Ich sehe nur die Readings.
Es gibt auch neue Readings: zb. "0B.1-Binary_0" Die BinaryNummer ist immer 1 mehr als die Registernummer

[justme1968]

regsiter 0B-Binary_outputs ist 1 byte lang und sozusagen die basis.

0B.0 ist das gleiche wie 0B. die einzelnen bits stehen in den regisertn 0B.1 bis 0B.8 für bit 0-7.

du solltest ein set auf 0B machen können mit einem hex wert zwischen 00 und FF oder auf jedes unterregister mit 0 oder 1 als wert.

das mit dem sezten eines einzelnen bits geht aber erst mit dem update von morgen.

ich habe gerade keinen panstamp mit antenne mehr frei um das selber zu testen. das kann ich morgen machen.

ansonsten ist mir eben gerade aufgefallen das du ganz oben in dem code das register scheinbar aus regtable.ino in die loop kopiert hast. d.h. es ist jetzt doppelt da. das wird auf jeden fall probleme machen. du bekommst morgen was besseres. vielleicht kannst du in inzwischen mal ein paar leds aufbauen das man dann auch was sieht :)

gruss
  andre

edit: ich hab schnell mal einen meiner panstamps mit dem original binouts sketch überschrieben. das setzen und löschen von B0 und auch der einzelnen unterregisgter geht mit der version aus dem update morgen. ich hab sie dir aber noch mal unten dran gehängt. fang mal zum testen mit dem original sektch an. das blinken muss man anders lösen weil es sonst nicht mit dem zwischen durch setzen synchronisiert ist.

wie soll es ganz genau aussehen:
- es wird immer der status aller led angezeigt
- jedes mal wenn sich an den werten etwas ändert soll der status sofort für 2 sekunden angezeigt werden
- wenn innerhalb der 2 sekunden ein update kommt fangen die 2 sekunden von vorne an
- danach soll alle 30 sekunden für 400ms angezeigt werden

richtig ?

edit2: und einen völlig ungetesteten schuss ins blaue für das blinken. das voltage register schaffe ich erst morgen :)
immer wenn er den status anzeigt sollte die batterie board led auch an sein.

[Tobias]

ich hab schnell mal einen meiner panstamps mit dem original binouts sketch überschrieben. das setzen und löschen von B0 und auch der einzelnen unterregisgter geht mit der version aus dem update morgen. ich hab sie dir aber noch mal unten dran gehängt. fang mal zum testen mit dem original sektch an. das blinken muss man anders lösen weil es sonst nicht mit dem zwischen durch setzen synchronisiert ist.

wie soll es ganz genau aussehen:
- es wird immer der status aller led angezeigt
- jedes mal wenn sich an den werten etwas ändert soll der status sofort für 2 sekunden angezeigt werden
- wenn innerhalb der 2 sekunden ein update kommt fangen die 2 sekunden von vorne an
- danach soll alle 30 sekunden für 400ms angezeigt werden

wow bis du schnell ... :)
ich habe mir am Mittwoch erst die Anreihklemmen im RM 3.5 bestellt da ich nur RM5 vorrätig hatte. Die werden warscheinlich heute oder morgen da sein, Montag werde ich mir ein paar 560/820 Ohm Vorwiderstände besorgen. Die LowCurrent LEDs (Rot/Gelb/Grün) hab ich hier jeweils im 50er Pack vorrätig.
Bin das ganze WE ab morgen nachmittag mit Frau und Kindern im Kurzurlaub. Komme deswegen erst am Montag abend wieder dazu.

Bisher hab ich es "nur" geschafft die Batterieanzeige zumindest vom soilmoiture-Sketch in den binouts.sketch zu bekommen. Ungetestet, Kompilieren tut's aber. Hab ihn statusmon.ino  genannt ;)

Vom Verhalten hast du oben die Punkte genau getroffen. Was würde eigentlich das 0A.TXIntervall bewirken? Das Intervall in dem das Panstamp-Modem aufwacht und sich syncronisiert?
Ich habe mal etwas drüber nachgedacht. Ich denke es ist durchaus WAF-Freundlich wenn der panstamp sich "nur" jede Sekunde syncronisiert. Ich hoffe das bringt schon etwas an Batterielebensdauer.
Übrigens hab ich bei Ebay schon D-Monoblock Bateriehalter mit Lötanschluss entdeckt ;)

[justme1968]

inzwischen hab ich auch etwas getestet. das blinken funktioniert im prinzip. der unterschied zwischen den 2s und den 400ms ist sichtbar aber nicht wirklich auffällig. ich vermute da sollte man noch etwas höher gehen.

hast du einen link zu den klemmen ?

0A ist normalerweise das intervall in dem der panstamp selber messwerte sendet.

das mit dem schlafenlegen müssen wir wirklich probieren. es könnte auch sein das die einsparung direkt wieder aufgefressen wird weil er dann statt nur zu lauschen zwei mal den eigenen sync status senden muss damit fhem weiss das gesendet werden kann.

wenn du magst checke ich das device description file unter diesem namen und mit meiner id ein.

viel spass im urlaub :)

gruss
  andre

[Tobias]

Hi Andre,
Hier der MonoblockHalter

Ich denke bei diesen vielen Anpassungen sollte es wirklich ein neuer Productcode un neuem XMLfile sein. Ich denke auch das "statusmon" sprechend ist...

Ich denke das dieses dann viel leichte anzupassen ist wenn man das ganze mit DauerLeuchtLEDs und externer Stromversorgung nutzen möchte.

Bzgl TXIntervall: sendet der panstamp unaufgefordert überhaupt mit dem binouts? Mir fällt gerade kein Fall ein.

Ich teste das dann nächste Woche mit angeschlossenen LED´s. Die Readings ändern sich nämlich nicht bei "regSet 0B.1 1". Bleibt alles leer..
Problem?
SWAP_Sent_unconfirmed   -> 13 Sent_unconfirmed

[justme1968]

und jetzt noch den link zu dem schraubklemmen :)

das mache ich glaube ich übers wochenende fertig.

das leuchten oder blinken kann man auch einfach konfigurierbar machen. dann ist nicht immer was am quelltext zu ändern.

er würde regelmässig den batteriestand senden.

die readings müssen sich ändern. wenn die unconfirmed hoch gehen stimmt etwas nicht. hast du den original binouts sketch? passt der product code? eventuell noch mal das attribut setzen. was zur zeit noch garnicht geht ist wenn ein device mit einer vorhanden adresse plötzlich einen anderen productcode verwendet. das device file wird dann noch nicht neu eingelesen. hast du das update von heute nacht bzw die version von oben drauf? mach doch bitte mal ein list auf das device.

wenn du global verbose auf 5 setzt siehst du ob fhem was absendet und ob vom panstamp was zurück kommt. beides siehst du jeweils auch an SWAP_lastRcv und SWAP_lastSend bei den internal values.

die readings sollten z.b. nach 'set <device> regSet 0B.3 1' so aussehen:
(siehe Anhang / see attachement)

gruss
  andre