Autor Thema: AskSin++ Library  (Gelesen 8736 mal)

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #15 am: 19 Oktober 2016, 21:19:51 »
Kann man ein Multichanneldevice aus verschiedenen Kanälen(MeterChannelGas, MeterChannelStrom) aufbauen, dann würde ich zwei channel bauen, die sich in der trigger() Funktion unterscheiden.

Du kannst in der trigger() mit number() die Nummer des Channels abfragen und dann halt eben Gas oder Strom machen. Der Timer kann auch im setup() gestartet werden:

void setup(Device* dev,uint8_t number,uint16_t addr) {
  Channel::setup(dev,number,addr);
  tick = seconds2ticks(5*60) * number();  // 5min Channel1 - 10min Channel2
  aclock.add(*this);
}

virtual void trigger (AlarmClock& clock) {
  // reactivate for next measure
  tick = seconds2ticks(5*60) * number();  // 5min Channel1 - 10min Channel2
  clock.add(*this);
  if( number() == 1 ) {
    // do Gas
  }
  else {
    // do Strom
  }
}
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #16 am: 19 Oktober 2016, 22:36:17 »
AlarmGas alarmGas = AlarmGas(sdev.channel(0));

Channel 0 gibt es nicht. Es geht bei 1 los.

Korrekt. Da alle Timer relativ zueinander und sortiert verwaltet werden, braucht man den Offset nur beim Ersten abziehen.
Als Verbesserung könnte man noch eine WDT-Kalibrierung am Start machen und diese dann bei der Offsetberechnung nutzen und den WDT erst wieder neu starten, nachdem der Interrupt da war.

das wars:
AskSin++ V0.1.0
CC init12..............3 - ready
Bat: 33
Strom
<- 10 00 20 5E 44 12 34 00 00 00 80 00 00 00 00 00 00
Gas
<- 10 00 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 01 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 02 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Gas
<- 10 01 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 03 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Gas
<- 10 02 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 04 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 05 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Gas
<- 10 03 20 53 44 12 34 00 00 00 00 00 00 00 00 00 00
Strom
<- 10 06 20 5E 44 12 34 00 00 00 00 00 00 00 00 00 00
Danke

Die Kalibrierung ist notwendig. Der genaue Wert  in % ergibt sich aber erst so nach 2 Minuten Test.
Bei mir sind es am Pro Mini  ca. 11,34%
Man muss aber auch die 8 Sekunden in eine Korrektur von 8192 ms verändern(glaube ich) - gleiches gilt für die anderen Zeiten.


Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #17 am: 19 Oktober 2016, 22:41:46 »
noch ein kleines Problem:

Zitat
Das Schreiben der Register sieht man auch im Funkverkehr. Achtung beim HM-ES-TX-WM musst Du immer den Config-Button drücken, nachdem Du iregndwas in den Registern mit FHEM geändert hast. Erst dann wird das ganze von FHEM aus gesendet.

bekomme im Log einen Fehler, wenn ich den ConfigButton drücke.
Das Lesen/Schreiben der Register scheint als command vorzuliegen, aber es kommt zu folgendem Fehler.

2016.10.19 22:26:29 2: nanoCUL: unknown message ERR:CCA
2016.10.19 22:26:27 2: nanoCUL: unknown message ERR:CCA

in der Übersicht steht
HM_441234 CMDs_pending getConfig clear msgEvents
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #18 am: 19 Oktober 2016, 23:08:37 »
habe jetzt folgendes herausgefunden:
(ERR:CCA -> Clear Channel Assessment)

was auch immer das ist

vielleicht hat der Fehler etwas damit zu tun das ich alle 5 Sekunden Gaswerte und alle 3 Sekunden Stromwerte gesendet habe. Damit war vielleicht zu viel Last auf der Leitung.

Jetzt kommt folgendes und das seit schon besser aus:
-> 0A 18 80 02 51 37 49 44 12 34 00
-> 10 19 A0 01 51 37 49 44 12 34 02 04 00 00 00 00 01
<- 1A 19 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
waitAck: 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
waitAck: 00
waitAck: 01
<- 1A 19 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
waitAck: 00
waitAck: 01
<- 14 19 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
waitAck: 00
waitAck: 01

irgendwie ist das ganze nicht stabil:
jetzt kommt wieder:

RESPONSE TIMEOUT:RegisterRead
« Letzte Änderung: 19 Oktober 2016, 23:14:35 von Dietmar63 »
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #19 am: 20 Oktober 2016, 01:02:36 »
weitere Frage:

warum werden die bytes der messages immer mit bit-shifting und bit-ands gefüllt:

    Message::init(0xc,msgcnt,0x70,Message::BIDI,t1,t2);

    pload[0] = humidity;
   
     pload[1] = (pres >> 8) & 0xFF;                      // air pressure
    pload[2] = pres & 0xFF;   

    pload[3] = (lux >> 24) & 0xFFFFFF;                    // luminosity
    lux = lux & 0xFFFFFF;
    pload[4] = (lux >> 16) & 0xFFFF;
    lux = lux & 0xFFFF;
    pload[5] = (lux >> 8) & 0xFF;
    pload[6] = lux & 0xFF;


funktioniert das ganze nicht auch so:

    memcpy(pload[0], &humidity,    sizeof(humidity));
    memcpy(pload[1], &pres,        sizeof(pres));
    memcpy(pload[3], &lux,         sizeof(lux));
dann könnte man sogar so vorgehen:
    uint8_t pp = 0
    memcpy(pload[pp], &humidity,    sizeof(humidity)); pp += sizeof(humidity);
    memcpy(pload[pp], &pres,        sizeof(pres)); pp += sizeof(pres)
    memcpy(pload[pp], &lux,         sizeof(lux)); pp += sizeof(lux)

    Message::length(base+pp);

besser wäre es dann vielleicht sogar ein makro zu bauen:
#define setPayload(VARIABLE)   memcpy(pload[pp], &VARIABLE, sizeof(VARIABLE)); pp += sizeof(VARIABLE)


Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #20 am: 20 Oktober 2016, 08:11:43 »
irgendwie ist das ganze nicht stabil:
jetzt kommt wieder:

RESPONSE TIMEOUT:RegisterRead

Hast Du den neuesten Code. Ich habe das Messagehandling letztens geändert. Möglicherweise hilft das hier. Das Ack auf die Nachricht kommt echt spät. Die "waitAck" Ausgabe kommt nach 300ms. Wenn dann noch kein Ack wird die Nachricht nochmals gesendet. Da sind bei Dir ganz schön viele Wiederholungen.

Ich werde auch mal das Versenden von Nachrichten an die Peers deaktivieren, wenn das Device im Config-Modus ist (Listen schreiben).
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #21 am: 20 Oktober 2016, 08:19:30 »
warum werden die bytes der messages immer mit bit-shifting und bit-ands gefüllt:

Der 8bit AVR verwendet little-endian Byteorder. Da stehen die Bytes in umgekehrter Reihenfolge im Speicher. Deshalb kannst Du die Werte, die mehrere Byte im Speicher brauchen, nicht einfach per memcpy() kopieren. Die Werte in den Messages sind big-endian. Durch das Shiften kümmert sich der Compiler um die richtige Reihenfolge. Der Code kann dann auch einfach so auf big-endian CPUs ausgeführt werden - da der Compiler bzw. die CPU das dann schon richtig machen. Ist einfach portierbarer.

Die Maske 0xff kann man sich wahrscheinlich auch sparen, da eh vorne mit 0 aufgefüllt wird. Ist eher zur Sicherheit, dass man dann auch wirklich nur ein Byte im Register hat und dieses in den Speicher schreibt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #22 am: 20 Oktober 2016, 11:58:53 »
Hast Du den neuesten Code. Ich habe das Messagehandling letztens geändert. Möglicherweise hilft das hier. Das Ack auf die Nachricht kommt echt spät. Die "waitAck" Ausgabe kommt nach 300ms. Wenn dann noch kein Ack wird die Nachricht nochmals gesendet. Da sind bei Dir ganz schön viele Wiederholungen.

Ich werde auch mal das Versenden von Nachrichten an die Peers deaktivieren, wenn das Device im Config-Modus ist (Listen schreiben).

ok, die allerneueste Version habe ich noch nicht.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #23 am: 20 Oktober 2016, 12:01:42 »
Der 8bit AVR verwendet little-endian Byteorder. Da stehen die Bytes in umgekehrter Reihenfolge im Speicher. Deshalb kannst Du die Werte, die mehrere Byte im Speicher brauchen, nicht einfach per memcpy() kopieren. Die Werte in den Messages sind big-endian. Durch das Shiften kümmert sich der Compiler um die richtige Reihenfolge. Der Code kann dann auch einfach so auf big-endian CPUs ausgeführt werden - da der Compiler bzw. die CPU das dann schon richtig machen. Ist einfach portierbarer.

Die Maske 0xff kann man sich wahrscheinlich auch sparen, da eh vorne mit 0 aufgefüllt wird. Ist eher zur Sicherheit, dass man dann auch wirklich nur ein Byte im Register hat und dieses in den Speicher schreibt.

ok, irgendwie dachte ich dass es für diese Art zu programmieren einen Grund geben muss.
Ich wurde wohl in die Irre geleitet, weil die bytes mit DDEX immer in der  richtigen Reihenfolge erscheinen.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #24 am: 20 Oktober 2016, 21:49:24 »
Das Einspielen der neuesten Version hat es leider auch noch nicht gebracht:
Kann den output auch nicht interpretieren. Vielleicht hängt das mit meinem nanoCul zusammen.
Pairing hat aber geklappt und die Nachrichten zu Strom und Gas werden auch empfangen.

<- 1C 0A 00 00 44 12 34 00 00 00 11 00 DE 70 61 70 61 35 35 35 35 35 35 70 03 01 00 00 00
*

*
-> 10 1F A0 01 51 37 49 44 12 34 00 04 00 00 00 00 00
<- 14 1F 20 10 44 12 34 51 37 49 02 02 01 0A 51 0B 37 0C 49 00 00
*
waitAck: 00
<- 14 1F 20 10 44 12 34 51 37 49 02 02 01 0A 51 0B 37 0C 49 00 00
*
*
waitAck: 01
*
-> 10 20 A0 01 51 37 49 44 12 34 01 04 00 00 00 00 01
<- 1A 20 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
*
*
waitAck: 01
<- 1A 20 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
waitAck: 00
<- 1A 20 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
*
waitAck: 01
<- 14 20 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
waitAck: 00
<- 14 20 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
*
waitAck: 01
*
-> 10 21 A0 01 51 37 49 44 12 34 02 04 00 00 00 00 01
<- 1A 21 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 08 00 95 FF 9C 00 7C 00 7D 27 7E 10 36 00 37 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 38 00 39 00 3A 00 3B 00 3C 00 3D 00 3E 00 3F 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
waitAck: 00
<- 1A 21 20 10 44 12 34 51 37 49 02 40 00 41 00 42 00 43 00 44 00 45 00 46 00 47 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 48 00 49 00 4A 00 4B 00 4C 00 4D 00 4E 00 4F 00
*
*
waitAck: 01
<- 1A 21 20 10 44 12 34 51 37 49 02 50 00 51 00 52 00 53 00 54 00 55 00 96 00 97 64
*
*
waitAck: 01
<- 14 21 20 10 44 12 34 51 37 49 02 98 00 99 0A 9A 27 9B 10 00 00
*
*
waitAck: 01
*
-> 0A 21 80 02 51 37 49 44 12 34 00
Strom
<- 10 0B 20 5E 44 12 34 51 37 49 00 00 00 00 00 00 00
*
waitAck: 00
<- 10 0B 20 5E 44 12 34 51 37 49 00 00 00 00 00 00 00
*
*
waitAck: 01
*
-> 0A 0B 80 02 51 37 49 44 12 34 00
Gas
<- 10 09 20 53 44 12 34 51 37 49 00 00 00 00 00 00 00
*
*
waitAck: 01
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #25 am: 20 Oktober 2016, 22:06:53 »
Wie sieht denn der RSSI Wert aus ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #26 am: 20 Oktober 2016, 22:21:20 »
Du könntest zum Testen auch mal den Timeout für das Empfangen des Ack hoch setzen. Derzeit werden maximal 300ms gewartet. Ich weiss nicht, was hier die "normale" Zeit ist. Dein Log sieht so aus, als würden auch 2 Acks kommen.

Ändere doch mal in Zeile 21 in Device.cpp die 30 auf 50. Dann wird 500ms auf das Ack gewartet.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #27 am: 21 Oktober 2016, 15:36:11 »
Wie sieht denn der RSSI Wert aus ?

Ich teste 2m vom nanoCul entfernt. Er ist noch nicht im produktivem Betrieb, habe ihn aber mal 5 Stunden vier Geräte zufällig an- ausschalten lassen - problemlos
Rssi:-45

Werde mal den timout hochsetzen und vielleicht mit einem echten CUL testen.
Komme aber erst am Sonntag abend dazu etwas neues auszuprobieren.

Wie sicher bist du dass die Nachricht des PowerMeters Gas korrekt aufgebaut wird. Habe mit der Variante von Trilu verglichen und kann auf dem ersten Blick keinen Fehler finden. Aber die Daten die ankommen sind Schrott.

Dietmar

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Offline papa

  • Developer
  • Full Member
  • ****
  • Beiträge: 322
Antw:AskSin++ Library
« Antwort #28 am: 21 Oktober 2016, 15:56:02 »
Wie sicher bist du dass die Nachricht des PowerMeters Gas korrekt aufgebaut wird. Habe mit der Variante von Trilu verglichen und kann auf dem ersten Blick keinen Fehler finden. Aber die Daten die ankommen sind Schrott.

Der Example HM-ES-TX-WM läuft bei mir seit einigen Wochen am Gaszähler und zählz auch fleissig mit. Was heisst den Schrott ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Dietmar63

  • Hero Member
  • *****
  • Beiträge: 2289
Antw:AskSin++ Library
« Antwort #29 am: 21 Oktober 2016, 16:17:07 »
Da ich per reset kein mtr*LED auf 500 (blink /Kwh) setzen kann weiß ich nicht was im Register ankommt. Im Code habe ich gesehen, dass der Wert des Registers {dx} einfach pro tick addiert wird.

Durch Rechnen (vielleicht falsch) glaube ich dass ich immer 20 pro tick addieren muss. Dann habe ich bei 500 Ticks pro Stunde genau 500*20 =10000centiKwH=1Kwh verbraucht. In Fhem kommen die Zahlen aber so nicht an. Nicht einmal annähernd ein vielfaches von 1,10,100. In Fhem scheinen die Daten verschoben zu sein. Vor Sonntag werde ich nichts machen können.

Ich weiß einfach noch nicht wo der Fehler liegt.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm