Arduino Asksin library

[unimatrix]

Hallo,

wollte mich nur mal "melden" - die letzten Wochen musste ich mich leider mit ganz anderen Dingen beschäftigen. Ich hoffe ich kann die neue Lib bald mal ausprobieren.

Freut mich dass immer noch daran gearbeitet wird! Es kommt auch wieder die Zeit, in der ich genügend Freizeit zum rumbasteln habe...

VG!

[MarcelK]

Hallo Horst,

zu mehr als einer oberflächlichen Durchsicht hat es mir bisher leider nicht gereicht (Baby, Hauskauf und so Späße haben gerade Prio), aber soweit sah die Sache wirklich sehr strukturiert und sauber aus. Hattest Du nicht irgendwann mal betont dass Du nicht vom Fach bist? Und dann sehe ich da Konzepte wie Delegates in C++ sowie einen absolut syntaktisch sauberen und durchgängig dokumentierten Code und kann's gar nicht wirklich glauben

Ich hab hier auf jeden Fall noch zwei PanStamps rumliegen die ganz gespannt auf Deine Library warten, hoffe ich komme da irgendwann mal dazu...

Danke für die Arbeit und viele Grüße, Marcel

[trilu]

Hi Marcel,

herzlichen Glückwunsch zu Baby und Haus, jetzt fehlt ja nur noch die Sache mit dem Baum
Ja, habe vor 2 Jahren begonnen mich mit Proggen zu beschäftigen. Struktur ist das Einzige das mir hilft nicht die Übersicht zu verlieren ... Aber Danke für die Blumen!
Viel Spass beim testen und hoffentlich auf ganz viel Input.

Viele Grüße
Horst

[mmatt]

Hallo trilu,

Ich finde es klasse, das Du nach eimem Jahr immer noch so motiviert bist, die Libary weiter zu enwickeln.

Freue mich schon, auf Experimente mit der neuen Libary.
Denke, in den Weihnachsferien wird es nicht langweilig

Ich habe da noch eine Frage, welche noch die "alte" Libary betrifft.
Im Powermode3 wird das CC1101 Module mit der Funktion "void CC110x::setPowerDownState()" abgeschaltet und so schlafen gelegt.
Ich nehme an, nachdem ich obige Funktion aufgerufen habe, kann das CC1101 Module weder empfangen noch senden.

Wie wird das CC110 Module wieder aktiviert, um nach Aufruf obiger Funktion Daten zu senden oder zu empfangen ?
Wie funktioniert das ?

Grüsse Martin

[trilu]

Hi Martin,

aufwecken geht mit detect burst.

Code Auswählen Erweitern

uint8_t CC110x::detectBurst(void) { // wake up CC1101 from power down state
// 10 7/10 5 in front of the received string; 33 after received string
// 10 - 00001010 - sync word found
// 7  - 00000111 - GDO0 = 1, GDO2 = 1
// 5  - 00000101 - GDO0 = 1, GDO2 = 1
// 33 - 00100001 - GDO0 = 1, preamble quality reached
// 96 - 01100000 - burst sent
// 48 - 00110000 - in receive mode
//
// Status byte table:
// 0 current GDO0 value
// 1 reserved
// 2 GDO2
// 3 sync word found
// 4 channel is clear
// 5 preamble quality reached
// 6 carrier sense
// 7 CRC ok
//
// possible solution for finding a burst is to check for bit 6, carrier sense

// set RXTX module in receive mode
cc1101_Select(); // select CC1101
wait_Miso(); // wait until MISO goes low
cc1101_Deselect(); // deselect CC1101
cmdStrobe(CC1101_SRX); // set RX mode again
delay(3); // wait a short time to set RX mode

// todo: check carrier sense for 5ms to avoid wakeup due to normal transmition
//Serial << "rx\n";
// return bitRead(hm.cc.monitorStatus(),6); // return the detected signal
return bitRead(monitorStatus(),6); // return the detected signal
}

Das ist die Funktion aus der alten Lib. In der Neuen habe ich es etwas anders gemacht, braucht dann nicht mehr so viel Zeit und ist damit energie sparender...

Viele Grüße
Horst

[setstate]

@trilu: Mit Freude entdecke ich deine neue Version der AskSin Lib und hoffte auf eine Verbesserung beim Pairing , weil ich mit der alten Version immer ein Dauerblinken der Status LED nach erfolgreichem Pairing bekomme. Dann half immer nur ein Reset (Arduino Strom aus/an). Mit der neuen Version funktionierte das Pairen auch wunderbar, wie bei den originalen Produkten.
Schade finde ich aber bei der neuen Version die vielen neuen "sophisticated" Aufrufe innerhalb des *.ino projects, wie "power_usart0_enable();", oder "regPCINT(PCMSK0,PCINT0);", das sollte in der Lib gekapselt bleiben. Ich glaube, das entspricht nicht der Arduino Philosophy. Ich weiß ja, dass du die ganze Mikroprozessor-Welt jetzt besser verstehst, aber als Arduino User will man eher auf "Do what I mean" Ebene bleiben. Lib einbinden und verständlich zusammen klimpern, was das Device machen soll.

Was ich eigentlich frage wollte ist: Leider kann ich zusammen mit der neuen Version nicht mehr die Arduino-Lib  IRremote  benutzen. https://github.com/shirriff/Arduino-IRremote. Vermutlich benutzt du jetzt die selben Timer, Interrupts, Ports oder was auch immer und die IRremote kann damit jetzt nix mehr senden. Ich baue gerade an einem kleinem Device, was per FHEM ein Gerät mittels IR ein/aus schalten soll und dabei auch den aktuellen Zustand übermittelt. Also Beamer einschalten und solange weiter senden, bis das Gerät an ist (5V am USB) und dann den Status des Beamers (an oder aus) zyklisch an FHEM übermitteln. Mit der alten Lib habe ich das wunderbar hinbekommen, nur die neue Lib verträgt sich nicht mit der IRremote Lib. Hast du eine Ahnung warum? Ich würde gerne die neue Version benutzen, weil sie die Batteriespannungsabfrage dabei hat, das Pairen auch als beendet von der LED angezeigt wird und weil ich denke, dass sie für meinen Anwendungsfall stromsparender ist.
Übrigens: die neue Lib bekomme ich unter der Arduino IDE 1.0.5 kompiliert, wenn ich statt:
HAL.CPP
struct s_pcINT {
   uint8_t cur = 0xff;
   uint8_t prev = 0xff;
   uint32_t time;
} static volatile pcInt[3];

das  dafür ersetze:

struct s_pcINT {
   uint8_t cur;
   uint8_t prev;
   uint32_t time;
} static volatile pcInt[3];

[trilu]

Danke für das Feedback.
Die "sophisticated" Aufrufe im main sketch sind nicht zwingend. Alles wesentliche für die Hardware, also Anbindung der Led,
des Funkmoduls, usw. finden in der HAL statt. Die Portsettings im main sketch kann man genauso gut über digitalwrite usw. erledigen.

Zur IR-Remote
Eigentlich dürfte nichts von der IR lib mit Asksin kollidieren.
IR nutzt per default den Timer2, Asksin nutzt Timer0 für die Zeitmessung.

IRremoteInt.h
// Arduino Duemilanove, Diecimila, LilyPad, Mini, Fio, etc
#else
  //#define IR_USE_TIMER1   // tx = pin 9
  #define IR_USE_TIMER2     // tx = pin 3
#endif

Ich kann mir nur vorstellen, dass du im Main sketch den timer2 noch abgeschaltet hast.
Ergänze den main sketch mal bitte um power_timer2_enable();
Dann sollte es eigentlich gehen.
An welchem Port hängt dein IR Empfänger?
Ach ja und um zu testen würde ich immer das Stromsparen abschalten, also hm.pw.setMode(0);

Viele Grüße
Horst

[setstate]

Hallo Horst,

danke für deine Lösungsvorschläge. Mit  power_timer2_enable(); funktioniert es jetzt. Die IR-LED hängt am PIN3.
Leider musste ich mich aber auch von der Komfort-Funktion delay(ms) verabschieden. Aber zum Glück konnte ich deinen waitTimer dafür benutzen, nach etwas Umbauen.

Viele Grüße
Mario

[setstate]

Mein Device wäre jetzt fertig und ich könnte es nutzen, leider musste ich feststellen, dass der Stromverbrauch viel zu hoch ist 15-20mA. Da ist die Batterie im Nu leer.
Mit dem RelaySketch (NewAskSin) liege ich auch bei 15mA, egal welcher Powermode. Auch wenn ich das CC1101 Modul abklemme, braucht der Relay-Sketch 3mA. Ich nutze Arduino Pro Mini 3,3V 8 MHz, Power LED abgeklemmt, 2xR03 Batterie an VCC/GND)
Mit dem Power Down Demo ( http://www.rocketscream.com/blog/2011/04/26/mini-ultra-8-mhz-current-consumption-part-2 )
komme ich auf 11µA runter, was mir zeigt, dass mein Messungen und das Board soweit okay ist.
Habt ihr noch Ideen, wo mein Fehler beim NewAskSin/HM_LC_SW1_BA_PCB ist? Alle Debug Defines habe ich auch rausgeschmissen.

[setstate]

Ich habe etwas geforscht. Es scheint etwas in der Power Class noch nicht optimal zu sein.

void PW::poll(void) {
.
// hier springt er immer raus, weil der Timer nie done wird
if (!pwrTmr.done()) return;   

void PW::stayAwake(uint16_t time) {
        // Das auskommentiert hilft, um den Timer ordentlich laufen zu lassen
   //if (time < pwrTmr.remain()) return;            
   pwrTmr.set(time);
}

Vermutlich ist eine Variable nicht initial gesetzt und hat einen Zufallswert (zufälliger Speicherinhalt)

Damit komme ich nach einigen Sekunden warten von 22,7mA auf 0,4-0,7mA (schnell schwankend) runter.
Schon mal was ...
Aber der Anfangsstrom von 23mA ist bei mir einfach zuviel, damit ich 2xAAA Batterien benutzen kann. Damit startet die Schaltung nicht und die LED am Pin 6 blinkt dauernd schnell.

[trilu]

Code Auswählen Erweitern

void PW::stayAwake(uint16_t time) {
        // Das auskommentiert hilft, um den Timer ordentlich laufen zu lassen
   //if (time < pwrTmr.remain()) return;           
   pwrTmr.set(time);
}


Auskommentieren ist keine gute Idee. Hier prüfe ich, ob bereits eine Wachzeit gesetzt ist und diese länger ist, als die die neu eingestellt werden soll.
Das Verhalten vom Relay Sketch stimmt so. Nach dem Booten bleibt der Sketch für 20 Sekunden wach und die Led blinkt.
Könnte man ändern um Strom zu sparen, aber so oft bootet ja das Device nicht.

0,4-0,7mA (schnell schwankend)

Das Schwanken kommt daher, das der Relay Sketch alle 250ms aufwacht, um zu prüfen ob ein Trägersignal aktiv ist, um gegebenenfalls einen Schaltbefehl zu empfangen. Wobei die 0,4ma aber immer noch sehr hoch sind. Vermutlich nutzt du einen Arduino Pro Mini und der Spannungsregler ist noch auf dem Board, oder die Led am SPI Bus die munter vor sich hin blinkt.

Bei meinem Test mit einem Panstamp, also ohne Spannungsregler und Led am SPI Bus bin ich auf eine theoretische Standby Zeit von 2 Jahren gekommen. Abhängig natürlich von der Kapazität der Batterien und der Schaltvorgänge. Ich bin von 2000ma Batterien ausgegangen. Kann aber heute Abend noch einmal das Messgerät dran hängen.

Die Frage ist aber auch, ob es für deine Anwendung nötig ist, das Funkmodul in den Lauschmodus zu schalten. Was ich verstanden habe, möchtest du IR Signale empfangen und dann weiter senden. Dazu würde ich einen Powermode ohne Empfangsmöglichkeit verwenden. Also Mode 2 oder 3.

Code Auswählen Erweitern

// 0 - 19.9ma; no power management
// 1 - wake up every 250ms, check for wakeup signal on air and stay awake accordingly, timer gets updated every 250ms
// 2 - deep sleep, wakeup every 250ms, not able to receive anything while sleeping, timer gets updated every 256ms
// 3 - 0.04ma; deep sleep, wakeup every 8 seconds, not able to receive anything while sleeping, timer gets updated every 8192ms
// 4 - 0.00ma; deep sleep, wakeup only on interrupt

Das sind die implementierten Powermodes. Mode 4 habe ich für Schalter vorgesehen. Hier schläft das Gerät komplett, bis eine Taste gedrückt wird, also ein Interrupt ausgelöst wird. Dann kann man einen Schaltbefehl senden, auf ACK warten und dann schläft das Gerät wieder bis zum nächsten Interrupt.

In Mode 2 und 3 wacht das Gerät regelmäßig auf und setzt die Systemzeit. Eignet sich gut für Sensoren. Durch das regelmäßige Aufwachen kann man kontinuierlich einen Meßwert lesen und bei Bedarf senden. Empfang muss explizit eingeschaltet werden.

Mode 1 ist speziell für batteriebetriebene Schaltaktoren, hier wird auf ein Burstsignal gewartet. Dazu muss das Funkmodul alle 250ms eingeschaltet werden, was der eigentliche Batteriefresser ist.

Bei deinem IR Device sehe ich nur eine Schwierigkeit. Soweit ich weiß, basiert der IR Sketch auf einem Timer und einem Interrupt. IR Diode hängt an Pin3 und löst bei jedem Potentialwechsel einen Interrupt aus. Die IR Lib prüft dann auf Preambel und so weiter. Nachdem aber jede Menge IR Licht in der Luft ist, schaltet das Ding ziemlich häufig ein...

Deshalb würde ich dir zum Powermode 2 raten. Da hier nur der Atmel wach wird, bewegt sich das im kleinen ma Bereich.
Ich werde bei Gelegenheit noch einmal die Powermodes testen, aber bisher hatte ich keine Probleme mit dem Relay Sketch, also mode1 scheint zu funktionieren.

Viele Grüße
Horst

[hsteinbo]

Hallo Horst,
zunächst einmal vielen Dank für die viele Arbeit mit der Bibliothek. Das ist die Wucht, und ich habe es auch geschafft, die NewAskSin Variante mit Panstamp in Betrieb zu nehmen. Das Dimmer Beispiel klappt wie eine eins.
Da ich versuchen möchte, empfangene IR Signale vom Panstamp zurück zum Fhem zu senden, wäre ich sehr  für Tipps dankbar, wie man einen Wert an Fhem senden kann.
In den Beispielen der neuesten Version ist ja schon ein Sensor vorhanden. Ließe sich das damit schon machen?
Oder lässt sich vielleicht das Dimmermodul dazu verwenden?
Ich habe den kompletten Thread gelesen, leider ist es mir nicht gelungen, die für die alte Version diskutierten Ansätze auf die neue Bibliothek zu übertragen.
Wenn Du mich in die richtige Richtung stupsen könntest, würde mir das sehr helfen. Vielen Dank schon im Voraus.

[setstate]

Genau Horst, die Info brauche ich auch noch für mein nächstes Projekt, Stromverbrauch-Ermittlung per EmonLib. Aber ich glaube, die Klasse "THSensor" ist zur Zeit nur die Hülle, da arbeitet Horst noch dran.

@hsteinbo: Du könntest aber in die andern Devices (Relay, Dimmer) eine neue Funktion ergänzen mit einem Aufruf von  hm->sendINFO_ACTUATOR_STATUS und damit vom Sketch aus einfache Integer Werte an FHEM übermitteln. Als Machbarkeitsstudie ausreichend, denke ich.

[trilu]

Es geht weiter mit der lib - habe mich am Wochenende um die Integration einer neuen Hardware gekümmert. Ist noch nicht komplett, aber Senden und Empfangen, sowie debuggen geht schon...

(http://busware.de/show_image.php?id=446&scalesize=0&nocount=y)
http://busware.de/tiki-browse_gallery.php?galleryId=49

Das ganze basiert auf einem radino, ein AVR 32U4 mit eingebautem Funkmodul
http://shop.in-circuit.de/products/170/radino-CC1101-868-915MHz

@setstate und hsteinbo
Das THSensor File ist noch ein Grundgerüst. Ich möchte hier eine Standard Sensor Class bauen, die von "außen" mit Meßwerten befüllt wird. Die Dimmer class und auch die Relay class sind Aktoren, die sollen nur ihren Status zurück liefern. Eignet sich also nicht für Meßwerte. Da ist die Sensor class schon besser.
Wie sehen denn die Werte aus, die ihr übertragen wollt?

Und ganz wichtig, was wollt ihr mit den übertragenen Meßwerten machen? Sollen die nur nach Fhem und angezeigt werden?
Oder wollt ihr mit den Meßwerten den Condition Table in Aktoren bedienen? Z.b. Lichtsensor schaltet Rolläden?

Bei dem IR Device bin ich mir nicht sicher, ob ich den Verwendungszweck schon begriffen habe. Soll das nur eine Bridge zwischen Wohnzimmer und FHEM sein, oder möchtest du per Fernbedienung z.b. einen Dimmer schalten? Sollen hier alle Fernbedienungsbefehle empfangen und gepostet werden, oder möchtest du filtern?

Viele Grüße
Horst

[setstate]

Ich würde die Messwerte nur im FHEM anzeigen / verarbeiten wollen. Ich nutze, außer Fensterkontakte zum Heizungsthermostat, keine Peers.