AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

Xent

Ich glaube schon, müsste ich mal nachschauen.
Denke das könnte höchstens bei den doppelten Messages helfen.
Aber bei dem Problem, das nichts mehr empfangen wird, wird das wohl wenig helfen, da das Empfangsproblem ja auch auftritt ohne dass ich was gesendet habe.

Xent

Ich versuche gerade ein periodisches Senden des Status einzubauen.
Allerdings wird in meiner Klasse scheinbar der Trigger nicht ausgelöst ...

template <class HalType,int PeerCount>
class SwitchChannel1 : public SwitchChannel<HalType,PeerCount> , public Alarm {

protected:
  typedef SwitchChannel<HalType,PeerCount> BaseChannel;

public:
  SwitchChannel1 () : BaseChannel(), Alarm(seconds2ticks(10)) {}

  virtual void trigger (AlarmClock& clock) {
    DPRINTLN("trigger");
    tick = seconds2ticks(10);
    clock.add(*this);
    //status(status(), DELAY_INFINITE);
  }

  void switchState(__attribute__((unused)) uint8_t oldstate,uint8_t newstate) {
....


Eigentlich müsste doch jetzt alle 10 Sek "trigger" auf der Konsole erscheinen oder nicht?

papa

Da fehlt der initiale Start. Bitte nicht im Constructor machen, da die Reihenfolge der Constructoren in C++ nicht defineirt ist. Somit könnte es passieren, dass man einen Alarm anmelden will, bevor die sysclock fertig aufgebaut wurde. Also am besten im setup() machen.

 
void setup(Device<HalType>* dev,uint8_t number,uint16_t addr) {
  BaseChannel::setup(dev,number,addr);
  sysclock.add(*this);
}


Zum Status senden bitte einfach


changed(true);


aufrufen. Das sollte dann eine StatuInfoMessage auslösen. Also so


virtual void trigger (AlarmClock& clock) {
    DPRINTLN("trigger");
    set(seconds2ticks(10));
    clock.add(*this);
    changed(true);
  }
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Danke, das funktioniert jetzt.
Ich lass jetzt alle 60 Sek die Statusmeldung senden, vielleicht hängt sich dadurch der CC1101 nicht mehr auf.
Da keine Rückmeldung von der CCU kommt sollte das den DutyCycle der Zentrale ja nicht beeinflussen.
In deiner Lib ist ja auch kein DutyCycle eingebaut oder?

Das einzig merkwürdige ist, dass die Ausgabe "trigger" 4 mal kommt aber nur einmal ein Status aller Kanäle gesendet wird:

trigger
trigger
trigger
trigger
<- 0E 15 A6 10 123456 000000 06 01 00 00 4B  - 1944
<- 0E 16 A6 10 123456 000000 06 02 00 00 4B  - 1958
<- 0E 17 A6 10 123456 000000 06 03 00 00 4B  - 2053
<- 0E 18 A6 10 123456 000000 06 04 00 00 4B  - 2152

papa

Das passt schon. Jeder Kanal hat einen Alarm. Der wird ausgelöst und landet in der Run-Queue. Dort wird das "trigger" ausfgerufen. Das macht nicht weiter, als die Ausgabe und das Changed-Flag im Channel zu setzen. Die ChannelDevice-Klasse prüft im "pollRadio" jeden Channel auf "changed" und sendet egebenenfalls den Status.
Man könnte einfach auch einen Alarm machen, der dann alle Channels auf "changed" setzt. Würde etwas Speicher sparen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Heute morgen ging schon wieder nichts ...

Könnte der Fehler vielleicht irgendwo beim pollRadio liegen, dass das nicht mehr richtig aufgerufen wird?
Hatte jetzt leider keinen PC zum Loggen dran und ich hab nicht ausprobiert, ob ein manuelles Auslösen über den Configtaster den Empfang wiederherstellt.
Sendet der ConfigTaster die Änderungen auch über das pollRadio oder triggert das direkt das Senden, Schalten usw.?

Es muss doch möglich sein einen stabilen Empfang herzustellen.
Es gibt ja immer hin die alternative Firmware für den Unterputzschalter und die haben ja auch nur CC1101 drin ...
Mal schauen ob ich in den master-Branch des NewAsksin mal meine Änderungen bezüglich des Schaltverhaltens einbauen kann ...

Xent

Hmm mit der NewAskSin Lib bekomme ichs irgendwie nicht hin.
Mit dem master hab ichs zumindest einbauen können, allerdings will der beim Pairing den Sicherheitsschlüssel ...
Keine Ahnung ob das daran liegt, dass noch irgendwas falsches im EEPROM steht oderso ...

Dann hab ich mich durch die Fehler des DevAES Branch gehangelt und das Example zum compilen gebracht.
Hier bekomme ich allerdings nur "ini" ausgegeben, obwohl eigentlich mehr kommen sollte.
Keine Ahnung woran das liegt, vielleicht werden zwei Ports die ich für die Relais nehme unterschiedlich geschaltet und es kommt daher zu nem kurzen oderso ...

Hab jetzt wieder deine  Lib drauf und werde bei nicht funktionieren schauen, ob man das Teil durch den Config Button wiederbeleben kann.

Mir ist gerade noch aufgefallen, dass beim Pairing scheinbar nicht der richtige Typ übergeben wird.
Bei mir in der CCU wird es als "HM-LC-SwX papa000000" erkannt.
Ich meine das war bei den ersten Versuchen nicht so.
Hab vor dem Pairing auch nen Reset gemacht.

Wenn das alles nichts bringt und der Empfang immer hängen bleibt, dann muss ich wohl ein 8-Fach Empfangsmodul nehmen und das dann an den Arduino hängen...

Xent

Mir ist noch was aufgefallen:

AskSin++ V1.0.6 (Jul 16 2017 13:22:14)
Address Space: 32 - 268
CC init12...................3 - ready
Invert active
HM-LC-SW4-SM
<- 0E 01 A2 10 123456 473071 06 01 00 00 00  - 266
-> 0A 01 80 02 473071 123456 00  - 417
waitAck: 01
<- 0E 02 A2 10 123456 473071 06 02 00 00 57  - 421
-> 0A 02 80 02 473071 123456 00  - 574
waitAck: 01
<- 0E 03 A2 10 123456 473071 06 03 00 00 56  - 578
-> 0A 03 80 02 473071 123456 00  - 731
waitAck: 01
<- 0E 04 A2 10 123456 473071 06 04 00 00 57  - 735
-> 0A 04 80 02 473071 123456 00  - 887


Vorher wurden die Statusnachrichten nicht quittiert.
Nun werden entsprechende Acks gesendet ...

papa

Da war es auch nicht gepairt.
Ich habe derzeit wenig Zeit, mich tiefer mit der Sache zu beschäftigen. Du musst also warten, oder es selber rausfinden. Ich gehe davon aus, dass die Ursache irgendwann erkannt und beseitigt wird.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

#384
Vielen Dank für deine bisherige Hilfe ;-)

Also eigentlich war der die ganze Zeit über gepairt.
Möglicherweise nicht ganz richtig.

Ich schau jetzt mal, wie es morgen früh aussieht.
Wenn es dann immer noch funktioniert, werde ich wohl umrüsten müssen.

Ist das mit dem HM-LC-SwX denn richtig?
Sollte die CCU nicht direkt erkennen obs nen HM-LC-SW2 oder HM-LC-SW4 usw ist?

papa

Nein - er sollte das ordentlich erkennen. Das Example ist als HM_LC_SW4_SM eingecheckt - DEVICE_MODEL. Wenn Du den OTA-Bootloader verwendest, kommt es drauf an, was im Bootloader abgelegt ist.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Der define für den OTA-Bootloader ist auskommentiert.

// define all device properties
#define DEVICE_ID HMID(0x12,0x34,0x56)
#define DEVICE_SERIAL "papa000000"
#define DEVICE_MODEL  HM_LC_SW4_SM
#define DEVICE_FIRMWARE 0x16
#define DEVICE_TYPE DeviceType::Switch
#define DEVICE_INFO 0x04,0x01,0x00
#define DEVICE_CONFIG CFG_LOWACTIVE_OFF


Ich meine auch, dass das beim vorherigen pairen korrekt erkannt wurde.
Naja funktioniert auch so ...

papa

Mach doch mal im Radio.h in  "void handleInt ()" die Debugausgabe rein. Dann wissen wir wenigstens, ob noch Interrupts vom CC1101 kommen, wenn nicht mehr empfangen wird. Wenn keine Interrupts mehr kommen, liegt es höchst wahrscheinlich am Receive-Code des CC1101 wenn noch Interrupts kommen eher bei pollRadio().
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Werde ich machen aber aktuell lief es jetzt ganz gut mit den automatischen Rückmeldungen.
Habe jetzt den Typ in den 2 Kanal geändert und neu gepairt.
Außerdem hab ich das Intervall deaktiviert.

Mal schauen was das Teil morgen früh sagt.

Xent

#389
Also ich hab jetzt noch nen kleinen Test eingebaut, ob der Arduino noch auf serielle Eingaben reagiert.
Wenn er nicht mehr auf Befehle reagiert, reagiert er trotzdem noch wenn ich was seriell schicke.
Also läuft er noch in den Loop und hat sich nicht komplett aufgehängt.
Es kommt keine Ausgabe mehr von handleInt().

EDIT: jetzt kurz nach meinem Test kamen doch wieder Ausgaben von handleInt und er reagiert wieder.
Habe den Arduino aber nicht resettet oder ähnliches ...
Sehr merkwürdig ...