FB Betty in FHEM einbinden

Begonnen von KölnSolar, 16 März 2017, 09:06:18

Vorheriges Thema - Nächstes Thema

papa

Hallo Chris,

kein Problem. Ich weiss ja auch noch gar nicht, ob ich überhaupt zeitlich dazu komme. Aber bevor jemand welche wegwirft, würde ich mir einfach eine weg legen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

mamalala

Achja,

habe grad wieder das alte Verzeichnis von meinem lokalen Betty-Kram wiedergefunden. Hätte da ein archiv anzubieten mit den originalen Quellcodes der Betty und der Adapter. Hatten wir ja damals vom Hersteller bekommen als es dann EOL war. Ein paar Datenblätter sind auch dabei.

Bei Bedarf bitte eine PN an mich.

Grüße,

Chris

KölnSolar

Hallo Chris,
gerne.  ;) :-*
Oder ob es i.O.(rechtlich) ist, ein Zip im 1. Post anzuhängen ? :-\ Würd ich dann machen(nur ich kann meinen Post ja ändern)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#153
Hi Telekatz,
hi Chris,
hi all,

meine Betty ist nach wie vor zufriedenstellend mit FHEM im Einsatz.  ;)

Da sich meine Systemlandschaft mittlerweile um Zigbee-Komponenten erweitert hat, stoße ich mit meinem alten Ansatz(Integration der aculfw) an meine Grenzen. Außerdem hab ich ein neues Projekt eines TFT-Projektors begonnen.

Nach der langen Zeit des einfach nur Benutzens, krame ich so peu à peu mein Betty-Wissen aus, baue mir meine Toolchain wieder auf und beginne wieder mit einer Weiterentwicklung.

Die bisher nicht von mir genutzte Telekatz-Adaption an FHEM per aculfw scheint mir, wo ich nun andere als nur 433/868- ASK/OOK Komponenten im Einsatz habe, der bessere Weg, um individuell FHEM per Betty zu steuern. Ich guck mal, ob ich die Telekatz-Betty-aculfw für einen busware-V3-Cul hinbekomme, um das weiter auszutesten.

Beim TFT-Projekt könnte ich mir den Einsatz des Scart- oder TAE-Adapters vorstellen. Die Mini-TFTs haben wohl eine proprietäre SPI-Schnittstelle. Müsste man doch an die Betty-Komponenten anschließen können.  :-\ Beim Scart-Adapter hätte man direkt eine 230V-Spanungsversorgung. Etwas problematisch sehe ich den knappen Speicherplatz.
Was denkt Ihr über diese Idee ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Telekatz

Der Scart Adapter könnte dafür taugen. Wenn die Daten nur vom CC1100 zur SPI-Schnittstelle durchgereicht werden müssen sollte der Speicherplatz reichen. Für diesen Zweck kann man die Firmware auch noch etwas ausmisten um Platz zu schaffen.

Vom TAE-Adapter rate ich ab. Die Hardware ist zu exotisch. Da ist zwar ein ARM drauf, aber eine Dokumentation zu diesem Typ gibt es frei zugänglich keine.

KölnSolar

Danke Dir für Deine Einschätzung. Ich guck mir dann mal den Scart-Adapter bzw. die betty_scart näher an. Damals hatte ich nur das flashen über die Betty ausprobiert. Ich mache dann in diesem alten Post dazu weiter.

2 generelle Fragen:
- ich fand damals Deinen FHEM-Ansatz ja u.a. nicht so gut, weil dem FHEM-System ein separater CUL spendiert werden muss.Ich hab mir mal die "Modulationsparameter" von boop angesehen. synchrones GSK..... Sollten wir nicht das Modulationsverfahren komplett auf eher übliches asynchrones OOK umstellen oder was spricht dagegen ?
- daraus resultiert dann auch die 2. Frage: Hast Du für den CUL das selbe Modulationsverfahren implementiert, wie es bereits zwischen boop u. betty_scart existierte ?(dann muss ich nicht mühsam die Register abglichen  ;))

Grüße Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Telekatz

Beim CUL habe ich die Einstellungen auf die der Betty angepasst. Zusätzlich habe ich dann noch die Frequenzeinstellungen von CUL und Betty wegen der unterschiedlichen Quarzfrequenzen etwas angepasst. Am Scart Adapter habe ich nichts angepasst. Da müssen noch die Einstellungen von der Betty Übernommen werden.

Zitat von: KölnSolar am 11 Oktober 2020, 10:40:57
Sollten wir nicht das Modulationsverfahren komplett auf eher übliches asynchrones OOK umstellen oder was spricht dagegen ?
Gegenfrage, was spricht dafür? OOK ist bei 433 MHz wohl deshalb weit verbreitet, weil man dann einfache und günstige RF Sender verwenden kann. Üblich sind dann aber auch weit geringere Datenübertragunsraten.

KölnSolar

ZitatGegenfrage, was spricht dafür?
Zitatweil dem FHEM-System kein separater CUL spendiert werden muss
, wenn man, u. das haben sicherlich viele FHEMler, bereits 433-OOK, also slowRF, einsetzt.

ZitatÜblich sind dann aber auch weit geringere Datenübertragunsraten.
Klar, aber den ursprünglichen Zweck der Betty ne Menge Daten zwischen Scart/TAE/FB zu übertragen gibt es doch eigentlich bei keiner Anwendung.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Telekatz

Es reicht aber nicht aus, nur auf OOK umzustellen. Du brauchst dann auch einen neuen Encoder/Decoder im SlowRF Teil der aculfw.

KölnSolar

ja, richtig, hatte ich nicht bedacht. Sollte aber kein Problem sein.

Toolchain auf dem neuen Rechner steht. Habe board.h u. CUL.c sowie das makefile für den busware_CUL angepasst. Kompiliert u. geflashed. Boop kompiliert u. geflashed. Betty-device wurde über autocreate angelegt. Die Tastendrücke kommen in FHEM an u. das settime funktioniert auch.

Dann werd ich nun  betty_scart an die geänderte Frequenz anpassen.

Oh, da passieren gerade fürchterliche Dinge. Massenhaft Betty-devices in FHEM, gefluteter event-monitor......tbc

....Erst dachte ich meine verschiedenen Bettys würden sich immer wieder ein "Echo" zuschmeißen. Nachdem ich wieder restarted hab, ist mir aber im Log aufgefallen, dass es alles scheinbar begann, als ich mit einem diesem CUL zugeordneten IT-device gesendet habe. Ich spekuliere, dass das mit der immer wieder von mir kritisch beäugten Funktionalität zu tun hat, dass das IT-Modul an den CUL-Einstellungen Veränderungen vornimmt u. wieder zurücksetzt. Ich vermute mal, dass aber nicht alle Parameter zurückgedreht werden und der CUL dann in einen völlig undefinierten Zustand gerät. :'(
2020.10.11 19:19:55 2: autocreate: define Betty_01 Betty 01
2020.10.11 19:41:39 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:40 2: autocreate: define Betty_00 Betty 00
2020.10.11 19:41:40 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:41 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:41 2: autocreate: define Betty_81 Betty 81
2020.10.11 19:41:42 2: autocreate: define Betty_04 Betty 04
2020.10.11 19:41:43 2: autocreate: define Betty_41 Betty 41
2020.10.11 19:41:44 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:45 2: IT IODev device didn't answer is command correctly:   raw => y0142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B200010400000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B20001
2020.10.11 19:41:45 3: CUL433: Unknown code 04000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B20001040001, help me!
2020.10.11 19:41:45 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:45 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:45 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:46 2: IT IODev device didn't answer is command correctly:   raw => y0142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B200010400000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B20001
2020.10.11 19:41:46 3: CUL433: Unknown code B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B200000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143, help me!
2020.10.11 19:41:46 3: CUL433 IT_set: Deckenlampe on
2020.10.11 19:41:46 2: IT IODev device didn't answer is command correctly:   raw => y8143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B200010400008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B2000104008143B2000104008141B2000104000143B2B2000104000143B2000104000143B2000104008142B1000104008142B2000104000142B2000104000141B20001
2020.10.11 19:41:46 3: CUL433 IT_set: Deckenlampe on
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Da denke ich seit Jahr u. Tag, dass Betty2 irgendein Akkuproblem hat und musste nun feststellen, dass es die Ladeschale ist, die scheinbar einen "Schaden" hat. Anstatt ca. 4,5V wie Ladeschale1 werden nur 0,4V geliefert.  >:(

Zum Glück gibt es ja noch Ladeschale3.  ;D Muss ich beizeiten mal gucken, was das defekt sein kann.  :(

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

Hi Telekatz,
kann es sein, dass durch Deine damalige Änderung "Change all IR protocols to hardware PWM" b&o u hx2262 kaputt gegangen sind ? Lirc mit Samsung läuft.
Ich bin jetzt wieder soweit, dass ich Deine Version laufen hab u. b&o sowie itv1(neu) teste.
Kann aber auch sein, dass meine Test-Betties spinnen. Bei der einen geht die Exit-Taste nicht, so dass ich keine RC-keys einstellen kann. >:( Dann hab ich immer wieder das Problem, dass nicht nachstellbar manchmal bei Tastendruck in ein anderes Menü(A/B/C/D) gesprungen wird. Bei manchen Encodern auch immer  :'( Selbst bei meiner Produktivbetty. Kann das an schlechten Akkus liegen ? :-\ Wo das fast nie auftritt, ist bei meiner aculfw-Implementierung von damals, um it-v1/-v3 zu senden. Das läuft immer noch sehr gut u. nutze ich am meisten.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Telekatz

Den Fehler bei hx2262 habe ich gefunden und behoben. Für b&o habe ich noch einen alten Branch gefunden, bei dem ich da Änderungen gemacht habe. Ich habe beides auf GitHub veröffentlicht. Teste mal, ob es bei dir funktioniert.

KölnSolar

Hi Telekatz,
das war es. Danke. B&O u. HX2262 funktionieren nun wieder.

Magst Du die attachten Dateien bei Dir einchecken ?    code.c - new lirc-encoder for Intertechno V1 added
   itv1   - new sample file for Intertechno V1 encoder
   beo4 - all RC-keys added
   samsung_ue46b6000 - change of codes for RC-keys: 0x08F7, // Prog-, 0x34cb, // VTX2


Dann mach ich mal mit dem scart-Adapter weiter....

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

KölnSolar

#164
weil ich ja kein serielles Interface am betty_scart hab, hab ich mir gedacht, dass die ping-Funktion zum einfachen Funktionstest brauchbar ist.

Um auch aus FHEM heraus testen zu können, habe ich dem Modul den set ping x Befehl(x=Adresse von 1-9) spendiert.
Beim Empfang dann das reading ping mit adress_ack, wenn ein acknowledge des ping gesendet wurde und ein adress_send, wenn nur der ping-Befehl gesendet wurde(in der Regel das Indiz, dass die "Adresse" den ping-Befehl nicht erwidert hat. Sendet die Betty ein ping an sich selbst(eigentlich ja widersinnig) antwortet FHEM mit einem acknowledge.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt