Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

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

Moderator: Co-Administratoren

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 14.03.2023, 11:22

der originale rhs sendet die zyklischen meldungen ziehmlich genau im abstand von 24h, wenn zwischen den zyklischen meldungen keine anderen meldungen (griffänderung oder batteriedeckeländerung) gesendet werden.

in alten logs könnte ich entsprechende telegramme raussuchen.

edit:
hier mal 4 messages, zwischendrin gab es nichts weiter, sieht man auch schön am fortlaufenden msg counter (39,3A,3B,3C).
der 24std timer wird auch bei einem trigger neu gestartet.

Code: Alles auswählen

2022.07.03 10:44:38.425 0: HMLAN_Parse: hmlan1 R:E1C1BE3   stat:0000 t:B2F1E1BF d:FF r:FFC1     m:39 A441 1C1BE3 1ACE1F 013200
2022.07.04 10:35:43.338 0: HMLAN_Parse: hmlan1 R:E1C1BE3   stat:0000 t:B8104ECD d:FF r:FFC0     m:3A A610 1C1BE3 1ACE1F 06010000
2022.07.05 10:26:32.077 0: HMLAN_Parse: hmlan1 R:E1C1BE3   stat:0000 t:BD2E7C86 d:FF r:FFC0     m:3B A610 1C1BE3 1ACE1F 06010000
2022.07.06 10:17:03.801 0: HMLAN_Parse: hmlan1 R:E1C1BE3   stat:0000 t:C24C67C3 d:FF r:FFC1     m:3C A610 1C1BE3 1ACE1F 06010000

nuiler
Beiträge: 207
Registriert: 15.04.2012, 11:07
Wohnort: Ostalbkreis / Deutschland

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von nuiler » 21.03.2023, 15:27

Ich habe auch HM-Sec-RHS. Wäre auch jemand bereit diese mir mit der alternativen AskSin-FW zu flashen?
www.nuiler.de
Raspberrymatic 3.57.4.20210320 rpi3

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 23.03.2023, 20:13

Ich hatte heut mal nach 24h (+/- 15min.) mit dem LogicAnalyzer geschaut und nix ist passiert.
Vermutlich muss dem MSP430 noch irgendwie gesagt werden, dass er den zyklischen Impuls senden soll.
Keine Ahnung wie. :|

VG,
Jérôme ☕️

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

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 25.03.2023, 11:02

schön, dass du mal geschaut hast.
jp112sdl hat geschrieben:
23.03.2023, 20:13
Ich hatte heut mal nach 24h (+/- 15min.) mit dem LogicAnalyzer geschaut und nix ist passiert.
das bedeutet also, dass während der halben stunde auf den leitungen A1-A4 beim rhs nichts passiert ist.
zunächst mal unerfreulich, aber um energy zu sparen, macht es ja sinn, dass auch der msp430 weniger tut, wenn keine zyklischen meldungen konfiguriert sind.
das würde doch aber bedeuten, dass bei jeder änderung des registers cycleInfoMsg auch der msp430 diese info bekommen müsste, also action auf A1-A4.
Vermutlich muss dem MSP430 noch irgendwie gesagt werden, dass er den zyklischen Impuls senden soll.
Keine Ahnung wie. :|
vermutlich wird es dir der HM-SCI-3-FM zeigen können, da er nach den xml files ebenfalls das register cycleInfoMsg hat, wakeup kann und den selben timeout (cyclic_timeout="88200") hat.

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 25.03.2023, 12:00

frank! hat geschrieben:
25.03.2023, 11:02
vermutlich wird es dir der HM-SCI-3-FM zeigen können
Hab ich schon analysiert und versucht, dem MSP des RHS die selbe Sequenz überzuhelfen.
Jedoch reagiert/antwortet er völlig anders als beim SCI

VG,
Jérôme ☕️

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

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 27.03.2023, 08:50

Ich trag hier mal meine Erkenntnisse zusammen, falls noch jemand eine Idee haben sollte.

Folgendes konnte ich an einem originalen HM-SCI-3-FM beobachten:
  • Mit deaktivierter zyklischer Statusmitteilung erfolgt nach jedem Zustandswechsel an den Schließerkontakten oder Übertragen von Konfigurationsdaten diese Kommunikation zwischen 328P und MSP430:
    sci ohne zykl.png
    sci ohne zykl.png (14.68 KiB) 277 mal betrachtet
    D8 = 328P -> MSP430, D9 = MSP430 -> 328P, D10 = 328P <> MSP430
  • D8 wird HIGH gesetzt. Nach 30ms antwortet der MSP430 mit einem HIGH Pegel. Es folgen dann 26 Takte, ohne jeglichen I/O auf D10.
  • Mit aktivierter zyklischer Statusmitteilung erfolgt nach jedem Zustandswechsel an den Schließerkontakten oder Übertragen von Konfigurationsdaten diese Kommunikation zwischen 328P und MSP430:
    sci mit zykl.png
    sci mit zykl.png (20.3 KiB) 277 mal betrachtet
    D8 = 328P -> MSP430, D9 = MSP430 -> 328P, D10 = 328P <> MSP430
  • Jetzt werden nach 6 Takten auf D10 scheinbar verschiedene Bits an den MSP430 übertragen. Auffällig ist nach dem 17. Takt (?) ein Low-Spike.
    Meine Annahme ist, dass an der Stelle die Übertragung vom 328P zum MSP430 endet und am 328P nun von OUTPUT auf INPUT gewechselt wird, um die Antwort vom MSP430 zu lesen.
  • Schiebe ich das selbe Muster auf den MSP430 des HM-Sec-RHS fällt zunächst auf, dass die H-Vorlaufzeit, bis der MSP430 antwortet, 40ms beträgt.
  • Höre ich auf, nach dem 17. Takt weiter Bits zu schieben, antwortet der MSP430 nicht.
  • Ich habe dann einfach mal das Muster vom SCI über die komplette Sequenz quick&dirty nachgebaut
    rhs nachbau.png
    rhs nachbau.png (16.67 KiB) 277 mal betrachtet

Ob es funktioniert? Keine Ahnung.
Falls es jemand testen möchte, ersetzt die poweroff() Methode im Sketch durch

Code: Alles auswählen

    void powerOff() {
      DDRC=B00001001;
      for (uint8_t i=0; i < 26; i++) {
        PORTC |= _BV(PC1);                //SET OUT    H
        while (!(PINC & (1 << PC2)));     //WAIT WHILE L
        PORTC &= ~_BV(PC1);               //SET OUT    L
        while (PINC & (1 << PC2));        //WAIT WHILE H
             if (i == 6)  PORTC |=  _BV(PC3);
        else if (i == 7)  PORTC &= ~_BV(PC3); 
        else if (i == 8)  PORTC |=  _BV(PC3); 
        else if (i == 9)  PORTC &= ~_BV(PC3); 
        else if (i == 11) PORTC |=  _BV(PC3); 
        else if (i == 15) PORTC &= ~_BV(PC3); 
        else if (i == 16) PORTC |=  _BV(PC3);
        else if (i == 17) { PORTC &= ~_BV(PC3); PORTC |= _BV(PC3); } // kurzen L-Spike erzeugen
        else if (i == 18) PORTC &= ~_BV(PC3); 
        else if (i == 21) PORTC |=  _BV(PC3); 
        else if (i == 22) PORTC &= ~_BV(PC3); 
        else if (i == 23) PORTC |=  _BV(PC3); 
        else if (i < 25) _delay_us(700);
      }
      DDRC=B00000001;
      
      hal.led.ledOff();
      hal.radio.setIdle();
      LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
    }
  
Zuletzt geändert von jp112sdl am 27.03.2023, 09:46, insgesamt 1-mal geändert.

VG,
Jérôme ☕️

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

sickboy2711
Beiträge: 250
Registriert: 12.11.2011, 16:58
System: CCU
Wohnort: Schweiz
Hat sich bedankt: 25 Mal
Danksagung erhalten: 6 Mal

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von sickboy2711 » 27.03.2023, 09:10

Hallo Jerome

Danke für deine Arbeit.
Ich habe noch einen Sensor ausgebaut bei mir liegen und werde den modifizierten Sketch heute Abend mal flashen.

Soll ich dann noch irgendwas und der Zentrale protokollieren?

Gruss

Daniel

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 27.03.2023, 09:47

sickboy2711 hat geschrieben:
27.03.2023, 09:10
Soll ich dann noch irgendwas und der Zentrale protokollieren?
Nein, das einzig zielführende wäre ein Mitschnitt der 168P<>MSP430 Kommunikation bei einem originalen (noch funktionierenden) HM-Sec-RHS.

VG,
Jérôme ☕️

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

frank!
Beiträge: 20
Registriert: 09.03.2021, 10:05
System: Alternative CCU (auf Basis OCCU)

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von frank! » 30.03.2023, 13:04

hallo jerome,
beeindruckende und informative ergebnisse, die du gepostet hast.

Auffällig ist nach dem 17. Takt (?) ein Low-Spike.
Meine Annahme ist, dass an der Stelle die Übertragung vom 328P zum MSP430 endet und am 328P nun von OUTPUT auf INPUT gewechselt wird, um die Antwort vom MSP430 zu lesen.
perfekt erkannt, würde ich meinen. faszienierendes werkzeug, dieser kleine analyzer.

einfaches an- und ausschalten würde allerdings einfacher funktionieren.
bis zu 17 bit werden an den msp gesendet und bis zu 8 bit gibt es als antwort darauf.

wenn ich alle möglichen 17 bits nutze, ergibt "10111100101000000" dezimal 96576.
das wäre schon nah an 86400 sekunden für 24 stunden.
da diese kommunikation auch bei jedem zustandswechsel erfolgt, würde der timer dadurch immer zurückgesetzt, also neu gestartet werden. und mit "00000000000000000" wird der timer nicht gestartet.

andererseits stelle ich mir dann die frage: warum ständig so eine "grosse und fixe" zahl übertragen?
oder: was passiert dann bei konfiguriertem EVENT_DELAYTIME (0-7620)? wacht er dann bei statuswechsel erst auf, legt sich wieder hin, und wacht nach EVENT_DELAYTIME nochmal auf?
und bei MSG_FOR_POS_A,B,C kann man "NO_MSG" konfigurieren, sodass er dann gar nicht aufwachen müsste. oder wird nur die funkmessage verhindert?

fragen über fragen. da bräuchte es noch viele tests mit unterschiedlichen konfigurationen, um die genaue logik zu ermitteln.
ein mitschnitt beim originalen rhs wird sicherlich ähnlich komplex sein.


kleiner unterschied
bei der erzeugung des signals "D0" beim rhs nimmst du gegenüber eq3 offensichtlich einen etwas anderen weg.
beim sci ist die pausendauer scheinbar immer konstant. du verkürzt die pausendauer bei jeder änderung vom signal "D2".
absicht?

ich werde demnächst mal den neuen sketch testen.

gruss frank

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Defekte HM-Sec-RHS mit AskSin-FW wiederbeleben?

Beitrag von jp112sdl » 30.03.2023, 13:36

frank! hat geschrieben:
30.03.2023, 13:04
faszienierendes werkzeug, dieser kleine analyzer.
So klein ist der nicht. Ich hab mir vor ein paar Wochen ein Rigol DS1104Z Plus + RPL1116 LogicProbe gegönnt.
Das Gefrickel mit PulseView am Laptop war nix für mich.
frank! hat geschrieben:
30.03.2023, 13:04
wenn ich alle möglichen 17 bits nutze, ergibt "10111100101000000" dezimal 96576.
das wäre schon nah an 86400 sekunden für 24 stunden.
Wobei es deinen Aufzeichnungen nach immer knapp unter 24 Stunden (ca. -9 Minuten) sind?
Aber möglicherweise ist es auch nur ein Vielfaches der zyklischen Aufweckzeit, die Übertragen wird inkl. einer Checksumme.
Und die Antwort ist dann die Checksumme als Kontrolle, damit der AVR weiß, dass die Übertragung zum MSP korrekt war.
frank! hat geschrieben:
30.03.2023, 13:04
oder: was passiert dann bei konfiguriertem EVENT_DELAYTIME (0-7620)? wacht er dann bei statuswechsel erst auf, legt sich wieder hin, und wacht nach EVENT_DELAYTIME nochmal auf?
und bei MSG_FOR_POS_A,B,C kann man "NO_MSG" konfigurieren, sodass er dann gar nicht aufwachen müsste. oder wird nur die funkmessage verhindert?
Interessanter Ansatz, das werd ich am Wochenende mal prüfen.
frank! hat geschrieben:
30.03.2023, 13:04
ein mitschnitt beim originalen rhs wird sicherlich ähnlich komplex sein.
Aber man hätte dann mal eine Signalverlaufsvorlage ^^
frank! hat geschrieben:
30.03.2023, 13:04
beim sci ist die pausendauer scheinbar immer konstant. du verkürzt die pausendauer bei jeder änderung vom signal "D2".
absicht?
Nein, ist mir noch gar nicht aufgefallen.
Dann müsste das _delay_us wohl auch nach jedem PORTC &= ~_BV(PC3); kommen.

VG,
Jérôme ☕️

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

Antworten

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