Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

Antworten
Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 29.12.2021, 19:34

Letztes Jahr hatte ich einen Nachbau und Modifikation von Papas HM-LC-Bl1-FM Sketch für Velux Rolladen und gemischtem Batterie-/Netzbetrieb an einem Netzfreischalter als Prototypen aufgebaut.

Inzwischen habe ich eine Platine dafür entwickelt und bin dabei die Firmware zu verfeinern und zu testen:
HM-LC-Bl1-FM_DG.ino.txt
(7.3 KiB) 33-mal heruntergeladen
Bei drei Herausforderungen brauche ich ein wenig 'Anschubhilfe' von Euch:

1. Die mit der Uhr gemessenen Fahrzeiten (=Bestromungszeiten des Veluxmotors) sind ca. doppelt so groß, wie im WebUI eingegeben. Es wird ein Arduino Pro Mini mit 8 MHz Resonator als Taktquelle verwendet. Wenn der Takt durch geeignete Einstellung der Fuses auf Pin B0 nach draußen gegeben wird, kann ich 7,957 MHz Taktfrequenz messen, also OK. Die kleine Abweichung erklärt also nicht die ca. 2x Abweichung der Fahrzeiten. Wie kann ich die Fahrzeit richtig einstellen? In AsksinPP/Blind.h fand ich nicht den richtigen Ansatzpunkt.

EDIT: Ein 'Restore Config' unter RM devconfig ändert nichts:
Restore Config.png
2. Beim Programmieren mit avrdude mit der Kommandozeile, sowohl beim Setzten der Fuses als auch beim Flashen eines neuen Hex Files bekomme ich unter Linux OS immer beim ersten Aufruf die Fehlermeldung

Code: Alles auswählen

       Using Port                    : usb
       Using Programmer              : stk500v2
       avrdude: usbdev_open(): cannot open device: Input/output error
       avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)
Der zweite oder dritte identische Aufruf klappt dagegen. Dann geht sowohl das Setzten von Fuses als auch das Flashen eines HEX Files. Woran kann das liegen? Aus der Arduino IDE klappt das 'Hochladen mit Programmer' nie.

3. Der 'Batteriebetrieb' wird von NiMH-Akkumulatoren versorgt. Eine Spannungsmessung im Sketch am Ende eines Schaltvorgangs funktioniert bereits. Nun sollen die Akkus über einen Widerstand R18 und schaltbaren FET Q3 und eine Diode D10 aufgeladen werden, wenn die Akkuspannung unter eine Mindestspannung fällt und bis eine Maximalspannung nicht überschritten wird. Frage: Wie kann ich (einfach) eine periodische Messung der Akkuspannung durchführen, z.B. alle 20 Minuten, und dann basierend auf den Spannungsvergleichen den LadeFET ein- oder ausschalten? Kann ich das mit einem zweiten Messkanal machen, z.B.

Code: Alles auswählen

class Channel2 : public Channel<Hal, List1, EmptyList, List4, PEERS_PER_CHANNEL, List0>, public Alarm {
  public:
    Channel2 () : Channel(), Alarm(0) {}
    virtual ~Channel2 () {}

    virtual void trigger (__attribute__ ((unused)) AlarmClock& clock) {
      seconds2ticks(MEASUREMENT_INTERVAL);
      //...
    }

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

    void init() {
      //...
    }

    uint8_t status () const {return 0;}
    uint8_t flags () const {return 0;}
};
Gibt es einen (noch) einfacheren Weg?

Vielen Dank im Voraus für Eure Hilfe!
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 30.12.2021, 09:31

Hier noch die Ausgaben im seriellen Monitor für je eine Aufwärts- und Abwärtsfahrt mit eingestellten WebUI Fahrzeiten von 20 Sekunden und 10 Sekunden:

Code: Alles auswählen

1. WebUI Fahrzeit 20 Sekunden



09:12:35.795 ->  debounce
09:12:35.861 ->  pressed
09:12:36.061 ->  released
09:12:36.061 -> -> 0B 18 02 40 5932AF 5932AF 01 05  - 39264
09:12:36.061 -> jumpToTarget: 6 1
09:12:36.061 -> setDestLevel: 200
09:12:36.061 -> Switch from 06 to 01   delay: 00000000
09:12:36.493 -> Accumulator voltage: 3763
09:12:36.493 -> Switch from 01 to 02   delay: 00000032
09:12:36.957 -> Accumulator voltage: 3763
09:12:36.957 -> 
09:12:37.422 -> calcDriveTime: 200 - 200 - 220
09:12:37.422 -> Switch from 02 to 08   delay: 00000898
09:12:40.113 -> <- 0E 19 A2 10 5932AF 123456 06 01 00 D0 33  - 40863
09:12:40.246 -> -> 0A 19 80 02 123456 5932AF 00  - 40988
09:12:40.246 -> waitAck: 01
09:13:15.744 -> Switch from 08 to 03   delay: 00000000
09:13:15.744 -> New Level: 200
09:13:16.209 -> Accumulator voltage: 3763
09:13:17.372 -> <- 0E 1A A2 10 5932AF 123456 06 01 C8 80 43  - 43962
09:13:17.472 -> -> 0A 1A 80 02 123456 5932AF 00  - 44087
09:13:17.472 -> waitAck: 01
09:13:28.873 -> ignore 19 ED A2 03 64935B 123456 D4 C1 89 EC 2D 50 BF DF C5 66 F8 0E BB 35 7F 95  - 44587
09:14:39.493 ->  debounce
09:14:39.685 ->  pressed
09:14:39.745 ->  released
09:14:39.745 -> -> 0B 1B 02 40 5932AF 5932AF 02 03  - 44615
09:14:39.745 -> jumpToTarget: 3 4
09:14:39.745 -> setDestLevel: 0
09:14:39.745 -> Switch from 03 to 04   delay: 00000000
09:14:40.157 -> Accumulator voltage: 3763
09:14:40.190 -> Switch from 04 to 05   delay: 00000032
09:14:40.623 -> Accumulator voltage: 3763
09:14:40.656 -> 
09:14:41.155 -> calcDriveTime: 200 - 200 - 220
09:14:41.155 -> Switch from 05 to 09   delay: 00000898
09:14:43.783 -> <- 0E 1C A2 10 5932AF 123456 06 01 C8 E0 3F  - 46213
09:14:43.916 -> -> 0A 1C 80 02 123456 5932AF 00  - 46338
09:14:43.950 -> waitAck: 01
09:15:19.426 -> Switch from 09 to 06   delay: 00000000
09:15:19.459 -> New Level: 0
09:15:19.925 -> Accumulator voltage: 3763
09:15:19.925 -> -> 0B 25 B0 01 123456 5932AF 01 0E  - 49276
09:15:20.024 -> <- 0E 25 82 10 5932AF 123456 06 01 00 80 40  - 49401
09:15:20.224 -> -> 0B 25 B0 01 123456 5932AF 01 0E  - 49606
09:15:20.356 -> <- 0E 25 82 10 5932AF 123456 06 01 00 80 3F  - 49731
09:15:21.053 -> <- 0E 1D A2 10 5932AF 123456 06 01 00 80 3F  - 50272
09:15:21.153 -> -> 0A 1D 80 02 123456 5932AF 00  - 50397
09:15:21.153 -> waitAck: 01
09:15:23.713 ->  debounce
09:15:23.770 ->  pressed
09:15:23.846 ->  released
09:15:23.846 -> -> 0B 1E 02 40 5932AF 5932AF 01 06  - 50905
09:15:23.879 -> jumpToTarget: 6 1
09:15:23.879 -> setDestLevel: 200
09:15:23.879 -> Switch from 06 to 01   delay: 00000000
09:15:24.345 -> Accumulator voltage: 3763
09:15:24.345 -> Switch from 01 to 02   delay: 00000032
09:15:24.777 -> Accumulator voltage: 3763
09:15:24.777 -> 
09:15:24.943 -> ignore 14 10 00 8E B03E3E 71F90C 2E 89 73 44 B6 4A 98 20 B1 A8 3F  - 51982
09:15:25.275 -> calcDriveTime: 200 - 200 - 220
09:15:25.275 -> Switch from 02 to 08   delay: 00000898
09:15:27.934 -> <- 0E 1F A2 10 5932AF 123456 06 01 00 D0 4C  - 52502
09:15:28.067 -> -> 0A 1F 80 02 123456 5932AF 00  - 52627
09:15:28.067 -> waitAck: 01
09:16:03.573 -> Switch from 08 to 03   delay: 00000000
09:16:03.573 -> New Level: 200
09:16:04.038 -> Accumulator voltage: 3763
09:16:05.201 -> <- 0E 20 A2 10 5932AF 123456 06 01 C8 80 4A  - 55603
09:16:05.335 -> -> 0A 20 80 02 123456 5932AF 00  - 55728
09:16:05.335 -> waitAck: 01
09:16:12.684 -> -> 10 29 B0 01 123456 5932AF 01 05 00 00 00 00 01  - 56225
09:16:12.817 -> <- 0A 29 80 02 5932AF 123456 00  - 56348
09:16:12.861 -> -> 0F 32 A0 01 123456 5932AF 01 08 0C 64 0E 64  - 56381
09:16:12.950 -> <- 0A 32 80 02 5932AF 123456 00  - 56498
09:16:13.000 -> -> 0B 3B A0 01 123456 5932AF 01 06  - 56526
09:16:13.082 -> <- 0A 3B 82 02 5932AF 123456 00  - 56647
09:16:16.375 -> -> 0B 45 B0 01 123456 5932AF 01 0E  - 57143
09:16:16.509 -> <- 0E 45 82 10 5932AF 123456 06 01 C8 80 3A  - 57272
09:16:16.707 -> ignore 0D E7 A6 10 460C1F 123456 06 01 00 00  - 57497
09:16:17.007 -> ignore 19 E7 A6 03 460C1F 123456 00 7C 01 BC 7C F2 C0 B0 07 31 D4 D2 C4 00 70 E7  - 57761





2. WebUI Fahrzeit 10 Sekunden



09:16:23.422 ->  debounce
09:16:23.526 ->  pressed
09:16:23.653 ->  released
09:16:23.653 -> -> 0B 21 02 40 5932AF 5932AF 02 04  - 57784
09:16:23.653 -> jumpToTarget: 3 4
09:16:23.653 -> setDestLevel: 0
09:16:23.653 -> Switch from 03 to 04   delay: 00000000
09:16:24.053 -> Accumulator voltage: 3763
09:16:24.053 -> Switch from 04 to 05   delay: 00000032
09:16:24.485 -> Accumulator voltage: 3763
09:16:24.519 -> 
09:16:25.017 -> calcDriveTime: 100 - 200 - 120
09:16:25.017 -> Switch from 05 to 09   delay: 000004B0
09:16:27.677 -> <- 0E 22 A2 10 5932AF 123456 06 01 C8 E0 2A  - 59383
09:16:27.777 -> -> 0A 22 80 02 123456 5932AF 00  - 59508
09:16:27.810 -> waitAck: 01
09:16:45.663 -> Switch from 09 to 06   delay: 00000000
09:16:45.696 -> New Level: 0
09:16:46.129 -> Accumulator voltage: 3763
09:16:47.260 -> <- 0E 23 A2 10 5932AF 123456 06 01 00 80 38  - 61483
09:16:47.393 -> -> 0A 23 80 02 123456 5932AF 00  - 61607
09:16:47.426 -> waitAck: 01
09:16:49.789 ->  debounce
09:16:49.839 ->  pressed
09:16:49.988 ->  released
09:16:49.988 -> -> 0B 24 02 40 5932AF 5932AF 01 07  - 62115
09:16:49.988 -> jumpToTarget: 6 1
09:16:49.988 -> setDestLevel: 200
09:16:49.988 -> Switch from 06 to 01   delay: 00000000
09:16:50.421 -> Accumulator voltage: 3763
09:16:50.421 -> Switch from 01 to 02   delay: 00000032
09:16:50.886 -> Accumulator voltage: 3763
09:16:50.886 -> 
09:16:51.385 -> calcDriveTime: 100 - 200 - 120
09:16:51.385 -> Switch from 02 to 08   delay: 000004B0
09:16:54.044 -> <- 0E 25 A2 10 5932AF 123456 06 01 00 D0 36  - 63713
09:16:54.177 -> -> 0A 25 80 02 123456 5932AF 00  - 63838
09:16:54.177 -> waitAck: 01
09:17:12.034 -> Switch from 08 to 03   delay: 00000000
09:17:12.034 -> New Level: 200
09:17:12.500 -> Accumulator voltage: 3763
09:17:13.661 -> <- 0E 26 A2 10 5932AF 123456 06 01 C8 80 34  - 65812
09:17:14.260 -> waitAck: 00
09:17:14.293 -> <- 0E 26 A2 10 5932AF 123456 06 01 C8 80 34  - 66451
09:17:14.792 -> -> 06 42 3A 71 B53A7C 000000 00 00 03 6E 00 01 09 08 31 03 4A 02 B4 23 0B 61 02 06 06 BE 03 19 03 00 13 03 08 F0 06 0E 03 41 26 01 10 22 01 34 00 00 00 00 00 00 2B 2C 19 57 4D CA 34 51 FE CA 00 00 00 02 25 02 4D B1 06 56 0A 00 00 DF 03 80 00 01 00 0A 00 32 00 64 00 58 02 B8 0B 70 17 A0 8C 02 08 04 05 09 01 00 03 06 00 00 00 00 81 03 E1 02 0E 03 E9 03 3F 03 1D 03 31 03 00 00 00 00 E9 09 00 00 00 00 1E 06 D5 06 AF 21 00 00 00 00 39 09 00 00 00 00 A0 0E 4D 07 B9 21 A5 0F AA 11 70 11 FE 0F 00 00 00 00 26 06 9B 21 DD 02 52 1B 00 00 00 00 23 06 E2 06 99 21 00 00 00 00 23 06 E2 06 BF 21 00 00 00 00 1D 09 E3 06 B3 21 E8 06 00 00 00 00 28 18 E4 06 B5 21 00 00 00 00 B6 08 48 06 A7 21 F2 17 00 00 00 00 B6 08 47 06 A5 21 EF 1A 41 63 63 75 6D 75 6C 61 74 6F 72 20 76 6F 6C 74 61 67 65 3A 20  - 67080
09:17:15.172 -> waitAck: 00
09:17:15.172 -> <- 0E 26 A2 10 5932AF 123456 06 01 C8 80 34  - 67215
09:17:15.689 -> waitAck: 00
09:17:15.738 -> <- 0E 26 A2 10 5932AF 123456 06 01 C8 80 34  - 67854
09:17:15.822 -> -> 0A 26 80 02 123456 5932AF 00  - 67979
09:17:15.822 -> waitAck: 01

und hier die WebUI Einstellung für die Fahrzeit von 10 Sekunden:
WebUI.png
Die delay() Statements im Sketch wurden auskommentiert, um auszuschließen, dass sie das 2x Phänomen verursachen.

Wie und wo kann ich die Expertenparameter einstellen, also z.B.:

SHORT_JT_RAMPON
SHORT_JT_REFON
SHORT_JT_RAMPOFF
SHORT_JT_REFOFF
HM_JumpTargets.png
HM_JumpTargets.png (9.59 KiB) 621 mal betrachtet
Ich habe in der RM bereits unter Benutzerverwaltung den Haken hinter 'Modus vereinfachte Verknüpfungskonfiguration aktivieren:' gelöscht. Unter 'Direkte Verknüpfungen' finde ich in der RM keinen Eintrag für meinen Rolladen Aktor.

Mein 2. Problem (>= 2 Aufrufe von avrdude für das Programmieren) hatte eine ganz banale Ursache: Wenn der Laptop im Akkubetrieb betrieben wird, sind mehrere Aufrufe vonnöten. Bei Netzbetrieb mit eingestecktem Netzgerät klappt es im ersten Aufruf.
Zuletzt geändert von FUEL4EP am 07.01.2022, 15:50, insgesamt 2-mal geändert.
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Benutzeravatar
stan23
Beiträge: 2038
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 582 Mal
Danksagung erhalten: 336 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von stan23 » 30.12.2021, 15:17

FUEL4EP hat geschrieben:
30.12.2021, 09:31
Ich habe in der RM bereits unter Benutzerverwaltung den Haken hinter 'Modus vereinfachte Verknüpfungskonfiguration aktivieren:' gelöscht. Unter 'Direkte Verknüpfungen' finde ich in der RM keinen Eintrag für meinen Rolladen Aktor.
Interne Direktverknüpfungen sind bei HM nicht vorgesehen bzw. können in der WebUI nicht angezeigt und bearbeitet werden.
Das geht nur mit externen Tools wie z.B. dem HomeMatic-Manager.

In deinem Fall sind es aber "interne Tasten" und die müssten sich in der Einstellung des Aktors konfigurieren lassen, so ist es zumindest bei meinem HM-LC-Bl1-FM_DC für mein 24 V Plissee.


Deine Schaltung sieht interessant aus. Machst du die Netzfreischaltung wegen der Leerlaufverluste? Ein Art Notbetrieb überdie Akkus ist nicht vorgesehen, oder?
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 30.12.2021, 15:30

Hi Marco,

Danke für Deinen Tipp mit dem Homematic-Manager. Das werde ich mal ausprobieren.

Deine Schaltung sieht interessant aus. Machst du die Netzfreischaltung wegen der Leerlaufverluste? Ein Art Notbetrieb überdie Akkus ist nicht vorgesehen, oder?

Die Netzspannung in meinem gesamten Dachgeschoss wird bei nicht angeschlossenen Lasten mit einem Netzfreischalter abgeschaltet, d.h. es liegt dann statt der 230V Wechselspannung nur noch eine kleine DC-Spannung an. Daher lassen sich klassische EQ-3 oder Velux Aktoren daran nicht betreiben.
Deswegen habe ich diese 'Bootstrap'-Schaltung entwickelt, die mit Akkubetrieb beginnt und dann die Netzspannung nur für den Fahrbetrieb des Rolladens einschaltet. Bereits bei der kleinen Last des 24V Netzteils schaltet der Netzfreischalter im Sicherungskasten die 230V auf. Die Leerlaufverluste werden als Dreingabe auf (fast) Null reduziert. Für das Fahren des Rolladens ist die (zugeschaltete) Netzspannung zwingend Voraussetzung. Ein reiner Akku Notbetrieb ist nicht möglich. Der Velux Motor zieht nominal 2A@24V.
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

jp112sdl
Beiträge: 12108
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2148 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von jp112sdl » 30.12.2021, 16:03

stan23 hat geschrieben:
30.12.2021, 15:17
Interne Direktverknüpfungen sind bei HM nicht vorgesehen bzw. können in der WebUI nicht angezeigt und bearbeitet werden.
Das geht nur mit externen Tools wie z.B. dem HomeMatic-Manager.
Für ein paar HB... Modelle habe ich das implementiert.
Ist aber noch nicht in der offiziellen JP HB Dev 5.8 drin.
Kommt dann mit der nächsten Version.
https://github.com/jp112sdl/JP-HB-Devic ... /issues/53

Und ist auch nur für HB-Varianten sinnvoll.
Bei Verwendung originaler eQ-3 HM-... Modelltypen wäre es gefährlich, da man dann die internen Peerings von Originalaktoren kaputt machen könnte.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 31.12.2021, 12:54

Den Homematic-Manager homematic-manager_2.7.0_amd64.deb bekomme ich leider nicht (mehr) zum Laufen. Selbst wenn ich alle Firewalls ausschalte, ist die Fehlermeldung 'undefined BidCos-RF (<IP_Raspberrymatic>:2001)'.

Ein testweise eingebauses delay

Code: Alles auswählen

      #define TEST_DELAY               20000
      
      DPRINTLN("TP 1");
      delay(TEST_DELAY);
      DPRINTLN("TP 2");
läuft genau 20 Sekunden. F_CPU beträgt 8000000, geprüft durch eine Debugausgabe.

Die Ausgaben im Serial Monitor von 'calcDriveTime: 100 - 200 - 120' passen auch zu den im WebUI eingestellten Fahrzeiten.
Nur die mit der Uhr gemessen Fahrzeit ist ca. doppelt so groß, siehe serial LOG oben.

Wo und wie werden die Ticks in Blind.h in physikalische Zeit anhand der Taktfrequenz umgerechnet? Wo werden die Timer gestellt?

EDIT: Fange nun an mich mit AsksinPP AlarmClock.h und AlarmClock.cpp vertraut zu machen und 'grabe' mich von dort zu den Statemachines von AsksinPP Statemachine.h und Blind.h vor :-) Irgendwo da liegt die Lösung für meinen ominösen Faktor 2x. Am Ende steht der Erkenntnisgewinn und das Verständnis für ein weiteres Stück von AsksinPP. Ich werde berichten, wenn ich der Ursache auf den Grund gestoßen bin.
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 01.01.2022, 12:41

Ich wünsche allen AsksinPP-Fans ein gutes, erfolgreiches und vor allem gesundes neues Jahr!

Mit Debugstatements in AsksinPP/Blind.h konnte ich die Ursache für meine ca. 2x zu großen Fahrzeiten einkreisen:

https://github.com/pa-pa/AskSinPP/blob/ ... ind.h#L201

Code: Alles auswählen

   virtual void trigger (AlarmClock& clock) {
      // add 0.1s
      ++done;
      if (done%20 == 0) {
        DPRINT("tr: ");  DDECLN(done);
      }
      set(millis2ticks(100));
      clock.add(*this);
    }
Bei jedem 20. Trigger wird eine Debugausgabe der Tick-Zählers 'done' gemacht.
Im seriellen Monitor liefert das:

Code: Alles auswählen

12:27:28.133 -> calcDriveTime: 300 - 200 - 320
12:27:28.133 -> Switch from 02 to 08   delay: 00000C80
12:27:28.133 -> blind start:  
12:27:28.133 -> start:  startlevel: 0
12:27:28.133 -> start:  fulltime  : 300
12:27:28.133 -> start:  done      : 0
12:27:30.127 -> tr: 20
12:27:32.388 -> tr: 40
12:27:35.916 -> tr: 60
12:27:39.439 -> tr: 80
12:27:42.968 -> tr: 100
12:27:46.494 -> tr: 120
12:27:50.022 -> tr: 140
12:27:53.546 -> tr: 160
12:27:57.105 -> tr: 180
12:28:00.601 -> tr: 200
12:28:04.158 -> tr: 220
12:28:07.681 -> tr: 240
12:28:11.205 -> tr: 260
12:28:14.730 -> tr: 280
12:28:18.256 -> tr: 300
12:28:21.780 -> tr: 320
12:28:25.302 -> tr: 340
12:28:27.097 -> Switch from 08 to 03   delay: 00000000
12:28:27.097 -> blind stop:  
12:28:27.097 -> New Level: 200
12:28:27.097 -> stop:  startlevel: 0
12:28:27.097 -> stop:  dx        : 200
12:28:27.097 -> stop:  done      : 300
12:28:27.097 -> stop:  fulltime  : 300
12:28:27.528 -> Accumulator voltage: 3763
Die Debugausgaben erfolgen im zeitlichen Abstand von ca. 3,5 Sekunden. Es sollten aber 20 * 0,1 Sekunden = 2 Sekunden sein.
Die Vermutung ist, dass mein Sketch (oder die AsksinPP Lib) einen falschen Clock 'sysclock' verwendet.

Woran kann das liegen?

Wie kann ich prüfen, welcher Takt von der trigger-Methode verwendet wird?
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Benutzeravatar
FUEL4EP
Beiträge: 586
Registriert: 01.11.2017, 17:26
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 76 Mal
Danksagung erhalten: 78 Mal
Kontaktdaten:

Re: Nachbau HM-LC-Bl1-FM für Velux Rolladen und Netzfreischalter

Beitrag von FUEL4EP » 01.01.2022, 13:57

Ich glaube, ich habe den 'Täter' erwischt :P

Wenn ich in meinem Sketch den Sleep Mode durch Idle Mode ersetze

Code: Alles auswählen

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    hal.activity.savePower<Idle<> >(hal);
  }
}

/* void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if ( worked == false && poll == false ) {
    hal.activity.savePower<Sleep<> >(hal);    //https://homematic-forum.de/forum/viewtopic.php?f=76&t=56948#p565118
  }
} */
dann stimmen die zeitlichen Abstände:

Code: Alles auswählen

13:49:35.724 -> Switch from 02 to 08   delay: 00000C80
13:49:35.724 -> blind start:  
13:49:35.724 -> start:  startlevel: 0
13:49:35.724 -> start:  fulltime  : 300
13:49:35.724 -> start:  done      : 0
13:49:37.684 -> tr: 20
13:49:39.713 -> tr: 40
13:49:41.739 -> tr: 60
13:49:43.734 -> tr: 80
13:49:45.727 -> tr: 100
13:49:47.754 -> tr: 120
13:49:49.782 -> tr: 140
13:49:51.777 -> tr: 160
13:49:53.773 -> tr: 180
13:49:55.801 -> tr: 200
13:49:57.829 -> tr: 220
13:49:59.825 -> tr: 240
13:50:01.821 -> tr: 260
13:50:03.848 -> tr: 280
13:50:05.842 -> tr: 300
13:50:07.870 -> tr: 320
13:50:09.865 -> tr: 340
13:50:10.896 -> Switch from 08 to 03   delay: 00000000
13:50:10.896 -> blind stop:  
13:50:10.896 -> New Level: 200
13:50:10.896 -> stop:  startlevel: 0
13:50:10.896 -> stop:  dx        : 200
13:50:10.896 -> stop:  done      : 300
13:50:10.896 -> stop:  fulltime  : 300
Immer ca. 2 Sekunden :)

Die Mutmaßung ist, dass die Tick-Korrektur während des 'vermeintlichen Schlafs' nicht korrekt ist. Der Aktor schläft ja während der Fahrzeit nicht und ist dann 'relativ' lange wach. Hier die Stelle in AlarmClock.h, wo die Korrektur gemacht wird:

https://github.com/pa-pa/AskSinPP/blob/ ... lock.h#L81

EDIT: Muss ich für eine korrekte Korrektur überhaupt 'regelmäße Schlafzeiten' wie z.B. bei Sensoren definieren?

Code: Alles auswählen

       set(seconds2ticks(updCycle));
       CLOCK.add(*this);
Bisher ist das für dieses WOR-Gerät nicht der Fall. Es schläft, bis es durch einen Burst geweckt wird oder eine der internen Tasten gedrückt wird.
Damit ist die 'Schlafzeit' unbestimmt.

EDIT²: Oder ist ein gemischtes Activity-Konstrukt wie beim HB-Dis-EP-42BW Sketch sinnvoll

Code: Alles auswählen

    if (ePaper.isWaiting()) {
      hal.activity.savePower<Idle<>>(hal);
    } else {
      hal.activity.savePower<Sleep<>>(hal);
    }
EDIT³: Der letzte Ansatz funktioniert :D :D

Hier in Kürze der loop Code:

Code: Alles auswählen

void loop() {
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  DPRINTLN("loop ");
  if ( worked == false && poll == false ) {
    /*if (hal.battery.critical()) {
      hal.activity.sleepForever(hal);
    }*/
    if (sdev.channel(1).shutter_in_motion()) {
      DPRINTLN("hal idle mode ");
      hal.activity.savePower<Idle<>>(hal);
    } else {
      DPRINTLN("hal sleep mode ");
      hal.activity.savePower<Sleep<>>(hal);
    }
  }
}
shutter_in_motion() wird aktiv geschaltet während der Rolladen fährt.

Die Stromaufnahme geht nach dem Fahren des Rolladens schön auf uA Werte zurück. Die Fahrzeit stimmt nun mit den im WebUI eingegebenen Werten überein. Und wieder ist ein Problem gelöst und ich habe wieder viel dabei gelernt :D 'Mischen' of activity modes is possible :D
Grüße

Ewald

Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“