"Frisch gewischte Böden, ohne davor Staub zu saugen: Der Hartbodenreiniger FC7 Cordless beseitigt alle Arten von trockenem und feuchtem Alltagsschmutz in einem Schritt." (Originaltext kaercher.com)
Dieses Produktversprechen bekommt man auf der Webseite des Herstellers, wenn man sich für die elektrischen Hartbodenreiniger FC7 interessiert. Wenn dieses Versprechen aber einmal nicht mehr wahr gemacht wird, dann erfahre ich von der Existenz dieser Geräte. Denn dann werde ich gebeten, einmal nachzusehen, warum etwas nicht mehr so tut wie es soll. So auch in diesem Fall. Die Bürsten (Walzen - wie auch immer diese Teile bezeichnet werden) drehen sich nicht mehr, so die Problembeschreibung. Oder genauer gesagt, sie drehen sich nur manchmal, wenn das Bodenteil zum beweglichen Stiel eine bestimmte Position einnimmt. Und da der Stiel (in dem die ganze Elektronik, wie Akkus, BMS und Bedienelemente untergebracht sind) in einem weiten Spielraum beweglich ist, liegt die Vermutung nahe, dass hier ein Kabelbruch oder ähnliche Kontaktprobleme vorliegen.
Das ist jetzt nicht gerade ein komplexes Problem, aber vielleicht interessiert den einen oder anderen doch, wie man das Problem beheben mit mehr oder weniger Aufwand beheben kann.
Im ersten Schritt sind der Schmutzwasserbehälter und die vier Reinigungswalzen zu entfernen. Danach können die Schrauben der Antriebsabdeckung und der Batterieabdeckung gelöst und die Abdeckungen entfernt werden.
Schrauben der Antriebsabdeckung
Schrauben der Batterie-/ Elektronikabdeckung
Der achtpolige Stecker links unten im Bild ist zu lösen. Er verbindet den Bürstenantrieb mit der Elektronik. Von den acht Polen des Steckers sind sechs Pins belegt. Ein roter und ein schwarzer Draht als Zuleitung zum DC - Motor (ja, hier wurde nur ein DC-Bürstenmotor verbaut und kein Brushless ...) weiters sind zwei braune Drähte zu den Stiften, die den Widerstandssensor für den Wasserstand im Schmutzwasserbehälter bilden, verlegt. Zwei blaue Drähte steuern das Magnetventil des Wasserzulaufs an.
Da der Fehler beim Antrieb des Motors liegt (je nach Lage des Stiels dreht sich der Motor, oder eben nicht), ist der Fehler möglicherweise in der Kabelverbindung von der Platine bis zum Motor zu suchen. Mit der Durchgangsprüfung des Multimeters war der Fehler schnell entdeckt. Die schwarze Leitung zum Motor war gebrochen.
gebrochene Leitung (schwarzer Draht zum DC Motor)
Die Bruchstelle befindet sich genau in dem Bereich, wo der Stiel in der Bodeneinheit beweglich befestigt ist. Genau hier werden der Kabelbaum und der Gummischlauch für die Wasserführung eingeführt. Das permanente Bewegen des Kabelbaumes führt dann längerfristig zwangsläufig zur Beschädigung und zum Bruch der Leitungen. Vor allem wenn man den Stiel in sehr flachen Winkeln benützt, um beispielsweise den Boden unter Kästen, Kommoden etc. damit reinigt.
Draht gelötet und mit Schrumpfschlauch isoliert
Die Reparatur habe ich hier mittels Zusammenlötens des Drahtes und Schützen mit einem Schrumpfschlauch durchgeführt. Den beschädigten Kabelschutzschlauch habe ich mit Isolierband umwickelt. Das sollte wieder einige Zeit halten. Da das Teil konstruktionsbedingt nicht bis in alle Ewigkeit halten wird, sollte bei der nächsten Reparatur der Kabelbaum komplett erneuert werden. (da der vermutlich nicht als Ersatzteil erhältlich ist, wird man wohl selber einen anfertigen müssen - dann aber gleich mit stabileren, hochflexiblen Drähten...)
Jetzt konnten die Komponenten wieder zusammengebaut werden. Die Rollen entsprechen den Farben grün / blau auf die Antriebsnaben aufsetzen und wieder alles zusammenschrauben.
Bei diesem Gerät sind offensichtlich gebrochene Kabelverbindungen und abgerissene Zahnriemen in der Motoreinheit die häufigsten Störfälle.
In diesem
Beitrag beschäftige ich mich ein wenig mit der Restauration – oder eher -Instandsetzung
eines Handheld Spiels das ich kürzlich zur Begutachtung erhalten habe. Es hat
die Bezeichnung „Tricky Traps“. Das bedeutet so viel wie „tückische oder
knifflige Fallen“
Das Spiel
"Tricky Traps" von Tomy ist ein mechanisches Geschicklichkeitsspiel,
das ursprünglich in den 1970er Jahren veröffentlicht wurde. Es besteht aus
einem labyrinthartigen Spielfeld, bei dem der Spieler eine kleine Metallkugel
durch eine Reihe von Hindernissen und Fallen navigieren muss. Ziel des Spiels
ist es, die Kugel erfolgreich durch das Labyrinth ins Ziel zu manövrieren, ohne
dass sie in eine der vielen Fallen fällt. Es stehen fünf Kugeln zur Verfügung.
Das Spiel läuft auf Zeit.
Tricky Traps
Spielmechanik:
Der Spieler startet das Spiel
mit einem Drehknopf, der einen kleinen Elektromotor in Gang setzt. Dieser
Motor treibt die „Fallen“ an und über ein Getriebe auch den Drehknopf
selbst. So wird der „Timer“ realisiert. Denn hat der Drehknopf etwa eine
dreiviertel Umdrehung hinter sich, so bleibt der Motor wieder stehen und das
Spiel ist beendet. Dies wird durch eine Kontaktfeder gelöst, die von einem
kleinen Steg unten am Drehknopf nach unten auf einen Gegenkontakt gedrückt
wird.
Ist das Spiel gestartet so kann
mit dem roten Knopf eine Kugel in die Bahn entlassen werden. Der weise
Knopf unten ist der eigentliche und einzige Spielknopf. Er hebt die Kugel
mit einem kleinen Zylinder an, sodass sie sich durch die verschiedenen
Teile des Spielfelds bewegen kann. Das muss man mit dem richtigen Timing
machen.
Auf dem Spielfeld befinden sich
zahlreiche Hindernisse wie rotierende Scheiben, kleine Rampen, schmale
Passagen und ein rotierender Magnet, die die Kugel stoppen oder in eine
Falle fallen lassen können.
Das farbenfrohe Design ist typisch für die
mechanischen Spiele der 70er und 80er Jahre. Es besteht aus Kunststoff, und die
beweglichen Teile sind meist in leuchtenden Farben gehalten.Die technischen Probleme, die bei solchen Spielen
immer wieder auftreten, sind:
ausgelaufene
Batterien, die meist Korrosion und Zerstörung der Kontakte verursachenSpröder Kunststoff,
der vor allem bei Zahnrädern auftritt, die auf Messingwellen aufgesteckt sind und
so zu rutschen beginnen. Auch halten so Gehäuseschalten oft nicht mehr
vernünftig zusammen.
Elektromotoren
deren Bürsten abgenutzt sind, sodass sie nicht mehr drehen.
Verharzte Fette
und Öle, die bewegliche Teile schwergängig machen.
Drähte und
elektrische Verbindungen, sie korrodiert und gebrochen sind
Alle diese
Punkte sind bei der Restauration immer wieder zu finden und müssen behoben
werden. Dies lässt sich auch mehr oder weniger einfach realisieren. Ich beginne
eigentlich nach einer vorsichtigen Öffnung und Begutachtung des Gerätes mit
einer kompletten Demontage und Reinigung der Teile. Dann versuche ich gebrochene
Kunststoffteile zu reparieren. Hier verwende ich soweit möglich verschiedene
Klebstoffe. Manchmal ist es auch notwendig, ein Teil auch mit einem 3D Drucker
nachzubauen. Dies setzt natürlich voraus, dass vom originalen Teil noch genug
vorhanden ist, um es passgenau nachzukonstruieren. Die elektrischen Komponenten,
sind bei diesen Geräten am einfachsten zu reparieren, da meist keine Elektronik
mit irgendwelchen Bauteilen mit nicht mehr hergestellten ICs verbaut sind.
In dem Beitrag mit dem Titel: "EVU Smartmeter mit ESP32 auslesen und Daten per MQTT senden" (link) habe ich beschrieben, wie sich die Smartmeter der EVUs über die Kundenschnittstelle auslesen lassen. Die Messdaten stehen dann als Topics über den mqtt Broker zur Verfügung und können in diversen Homeautomationen (HomeMatic, Homeassistant, etc.) weiterverarbeitet werden. Dazu benötigt man lediglich eine ESP32-Platine und ein paar wenige Kleinteile, um die Verbindung zum Smartmeter herstellen zu können. Als kleines Update habe ich den Aufbau (damals mit Stiftleisten auf Lochrasterplatine) mittlerweile ein wenig geschönt und eine Platine gefertigt.
Layout im Designtool
Der zugehörige Schaltplan entspricht im Wesentlichen auch der Skizze im damaligen Beitrag. Um ein wenig Komfort mit der neuen Platine zu erhalten, ist die Verbindung zur Kundenschnittstelle des Smartmeters über eine RJ-Buchse steckbar. Und auch die Spannungsversorgung habe ich über eine USB-Buchse realisiert.
Nach dem Bestücken und Aufstecken der ESP32 Platine bekam das Gerät noch ein kleines Gehäuse spendiert und verrichtet nun im E-Verteilerschrank seinen Dienst.
Die Hardware ist somit fertig und funktionstüchtig. Zum Thema Software habe ich mir auch überlegt, etwas zu ändern. Bis jetzt lief auf dem ESP ein Programm, das die Daten des Smartmeters entschlüsselt und dann per MQTT an die IP Adresse des Brokers gesendet hat. Da ich mittlerweile jedoch auch ein Anwender der ESPHome Integration in meiner HomeAssistant Umgebung bin, habe ich den ESP mit einem ESPHome Basisimage geflasht. Auf GitHub gibt es das Repository von Andre-Schuiki, auf dem er eine Version für ISKRA und SIEMENS Smartmeter für die Verwendung mit ESPHome veröffentlicht. Unter folgendem Link ist die Anleitung zur Installation zu finden: https://github.com/Andre-Schuiki/esphome_im350/tree/main/esp_home
Das Script für das ESPHome Graät sieht bei mir folgendermassen aus:
esphome:
name: kelagsmartmeter
friendly_name: KelagSmartmeter
libraries:
- "Crypto" # !IMPORTANT! we need this library for decryption!
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "da kommt der key rein des neu angelegten ESPHome Gerätes rein"
ota:
password: "das automatisch generierte ota passwort"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Kelagsmartmeter Fallback Hotspot"
password: "das automatisch generierte password"
captive_portal:
external_components:
- source:
type: local
path: custom_esphome
sensor:
- platform: siemens_im350
update_interval: 5s
trigger_pin: 26 # this pin goes to pin 2 of the customer interface and will be set to high before we try to read the data from the rx pin
rx_pin: 16 # this pin goes to pin 5 of the customer interface
tx_pin: 17 # not connected at the moment, i added it just in case we need it in the future..
decryption_key: "00AA01BB02CC03DD04EE05FF06AA07BB" # you get the key from your provider!
use_test_data: false # that was just for debugging, if you set it to true data are not read from serial and the test_data string is used
test_data: "7EA077CF022313BB45E6E700DB0849534B697460B6FA5F200005C8606F536D06C32A190761E80A97E895CECA358D0A0EFD7E9C47A005C0F65B810D37FB0DA2AD6AB95F7F372F2AB11560E2971B914A5F8BFF5E06D3AEFBCD95B244A373C5DBDA78592ED2C1731488D50C0EC295E9056B306F4394CDA7D0FC7E0000"
delay_before_reading_data: 1000 # this is needed because we have to wait for the interface to power up, you can try to lower this value but 1 sec was ok for me
max_wait_time_for_reading_data: 1100 # maximum time to read the 123 Bytes (just in case we get no data)
ntp_server: "pool.ntp.org" #if no ntp is specified pool.ntp.org is used
ntp_gmt_offset: 3600
ntp_daylight_offset: 3600
counter_reading_p_in:
name: reading_p_in
filters:
- lambda: return x / 1000;
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
counter_reading_p_out:
name: reading_p_out
filters:
- lambda: return x / 1000;
unit_of_measurement: kWh
accuracy_decimals: 3
device_class: energy
counter_reading_q_in:
name: reading_q_in
filters:
- lambda: return x / 1000;
unit_of_measurement: kvarh
device_class: energy
counter_reading_q_out:
name: reading_q_out
filters:
- lambda: return x / 1000;
unit_of_measurement: kvarh
device_class: energy
current_power_usage_in:
name: power_usage_in
filters:
- lambda: return x / 1000;
unit_of_measurement: kW
accuracy_decimals: 3
device_class: energy
current_power_usage_out:
name: power_usage_out
filters:
- lambda: return x / 1000;
unit_of_measurement: kW
accuracy_decimals: 3
device_class: energy
# Extra sensor to keep track of uptime
- platform: uptime
name: IM350_Uptime Sensor
switch:
- platform: restart
name: IM350_Restart
Seit ich mich mit Home Automatisierungen
beschäftige soll natürlich so viel wie möglich optimiert, vereinfacht
und unter den Aspekten der neuen Schlagworte „Green Electronics“,
„Nachhaltigkeit“, „Energiesparend“ … usw. angepasst und realisiert
werden. So schalten bei mir Geräte bei Nichtbenutzung oder
Nichtbeachtung ab, Stand-by Energieverbrauch wird weitgehend vermieden
und auch die menschliche Vergesslichkeit (Fenster offen gelassen im
Winter, oder vergessen Licht aus zu schalten) verhindert die IOT –
Technologie. Wie die Leser des Blogs mittlerweile schon wissen habe ich
hier Systeme wie HomeMatic, NodeRed und seit einiger Zeit Homeassistant
mit ESPHome, Zigbee2Mqtt usw. in Verwendung. Das Ziel ist natürlich
auch, alles Systeme Cloudfrei zu halten. Ich will nicht, dass die Daten
den Umweg über irgendwelche Server in Fernost nehmen um bei mir ein
Licht ein und aus zu schalten. Also soll möglichst alles im Kreis meines
eigenen Netzwerks stattfinden und nicht nach außen „telefonieren“ und
auch funktionieren wenn ich die Datenleitung kappe.
Bei diversen Lieferanten gibts es seit
langem, ein, für die Bequemlichkeit im elterlichen Ruheraum, äußert
praktisches Gerät. Ich spreche da von einer platzsparenden Möglichkeit,
die Flimmerkiste (heute auch Flat-TV genannt) im Raum unterzubringen.
Ich nenne hier nur Bezeichnungen wie:
Speaka Professional TV-Deckenhalterung
elektrisch motorisiert (1439178) oder MyWall HL46ML … etc. Manche von
diesen Gräten sind mit einer Funkfernbedienung steuerbar, andere
wiederum über die CloudApp von Tuya. Man kann die Tuya App zwar über die
Tuya IOT Entwicklungsumgebung umgehen und diese Geräte über die
Integration „TuyaLocal“ in seinen Homeassistant bringen – geht zwar –
ist aber eher eine „NUR“- Lösung. Die ideale Lösung ist aus meiner
Sicht, die Integration dieser Geräte ins ESPHome System. Am Beispiel
der Speaka Professional TV Deckenhalterung zeige ich, wie diese mit
einer kleinen Erweiterung ins ESPHome Netz und somit im Homeassistant
integriert werden kann. Diese Ausführung des SpeaKa Teils hat keine
Internet Anbindung und wird nur über eine Funkfernbedienung gesteuert.
TV Deckenhalter mit geöffneter Abdeckung
Systemübersicht
Das Systemdiagramm oben zeigt wie die Platine aufgebaut ist. Die
Stromversorgung kommt von einem Steckernetzteil mit DC 24V Ausgang bei
1,5A. Auf der Platine erkennt man noch einen unbestückten Bereich,
dessen Lötpads mit +3V3, GND und RX, TX Leitungen passend für einen
ESP8266 beschaltet sind. Ebenso ist eine USB Buchse zu erkennen. Diese
beiden Schnittstellen sind im Diagramm nicht berücksichtigt. Untersucht
haben wir die RX/TX Leitungen, die von den unbestückten Lötpads
(ESP8266) zum Microcontroller (1301 X 016B) geroutet sind. Doch hier
waren keinerlei Signale zu messen. (Vermutlich ist die Schnittstelle in
der geflashten Programmversion nicht aktiviert).
„Debug“ Drähte an den RX/TX und am RF-Chip
Dieser Weg bringt uns also nicht weiter.
Im nächsten Schritt haben wir uns angesehen wo die Steuersignale der
Funkfernbedienung herkommen, bzw. wie sie in weiterer Folge umgesetzt
werden. Der RF-Empfänger Chip hat 16 Pins und leider keinerlei
Beschriftung. Oder wurde sie entfernt. Die Versorgungsspannung des
RF-Chips liegt an Pin1 und Pin16 an, Pin2 und Pin3 ist mit einem Quarz
beschaltet und von Pin9 ist eine Leitung zum Microcontroller geroutet.
Das muss also der Datenausgang sein. Mit Hilfe der Software „PulseView“
von Sigrok und einem Fernost Logicanalyzer haben wir diesen Ausgang
mitgesnifft. Und siehe da, hier offenbarten sich Datenpakete mit einer
Dauer von 10.3ms. Die Software PulseView konnte das Protokoll nach
einigen Versuchen mit unterschiedlichen analysierten Datenraten als
RS232 Protokoll erkennen. So war es dann ein leichtes die empfangenen
und dekodierten Steuerbefehle zum Microcontroller zu protokollieren.
RF-Chip mit angeschlossener „Sniffer“ Leitung
Die Baudrate des RS232 Ports am RF-Chip Ausgangs beträgt 9600 bei
8N1. Es werden bei jedem gesendeten Befehl 10 Bytes in HEX empfangen.
Hier die Liste der Kommandos: (fehlende Byte folgen…)
Befehl
Byte0
Byte1
Byte2
Byte3
Byte4
Byte5
Byte6
Byte7
Byte8
Byte9
UP
0xAA
0x06
0x04
0x25
0x03
0xD5
0x01
0x00
0x02
0x55
DOWN
0xAA
0x06
0x04
0x25
0x03
0xD5
0x00
0x10
0x11
0x55
LEFT
0xAA
0x06
0x04
0x25
0x03
0xD5
0x55
RIGHT
0xAA
0x06
0x04
0x25
0x03
0xD5
0x55
BUTTON1
0xAA
0x06
0x04
0x25
0x03
0xD5
0x55
BUTTON2
0xAA
0x06
0x04
0x25
0x03
0xD5
0x00
0x08
0x09
0x55
MEM1
0xAA
0x06
0x04
0x25
0x03
0xD5
0x55
MEM2
0xAA
0x06
0x04
0x25
0x03
0xD5
0x55
OK
0xAA
0x06
0x04
0x25
0x03
0xD5
0x00
0x40
0x41
0x55
SET
xx
xx
xx
xx
xx
xx
xx
xx
xx
xx
Nachdem mit dem Logikanalyzer das Datenprotokoll gefunden war, versuchten wir über ein Terminalprogramm und einen USB zu TTL232 Converter die Daten an den Microcontroller zu senden. Dazu wurde der RF-Chip entfernt. Er zog den Pegel im Ruhezustand auf VCC und verhinderte ein paralleles Betreiben der "RS232 Transmitter".
Board ohne Chip mit Debugleitung
USB UART zum Senden der Befehle
Die Steuerbefehle aus oben dargestellter Tabelle konnten per Terminal Programm erfolgreich gesendet werden. Jetzt musste nur noch ein ESP32 Board diese Aufgabe übernehmen. Ein ESP32 NodeMCU Board aus dem Fundus wurde mit einem Basis ESPHome-Image bestückt und ins Homeassistant Netzwerk integriert. Dem ESPHome Knoten war jetzt nur noch beizubringen, über den TX Pin des ESP32 die Bytefolge bei entsprechendem Trigger im Homeassistant zu senden. Dazu wurde das ESP32 Board in auf der Platine befestigt und die VCC3V3, GND und TX Leitung zum PIN9 des ehemaligen RF Chip gelötet.
ESP32 am Board des Speaka Deckenhalters
Wieder im Deckenhalter eingebaut
In der ESPHome Webumgebung ist nun das folgende yaml Script hinzuzufügen.
esphome:
name: tvhalterung
friendly_name: TVHalterung
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "hier dein key beim Anlegen des device"
ota:
password: "hier dein ota password"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Tvhalterung Fallback Hotspot"
password: "hier wieder deins"
captive_portal:
uart:
tx_pin: 4
rx_pin: 5
baud_rate: 9600
# Example button configuration
button:
- platform: template
name: TV Halterung UP
id: tv_up
icon: "mdi:arrow-up-bold-outline"
on_press:
- logger.log: "Button pressed TV Up"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x01,0x00,0x02,0x55]
- platform: template
name: TV Halterung OK
id: tv_ok
icon: "mdi:stop-circle-outline"
on_press:
- logger.log: "Button pressed TV OK"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x40,0x41,0x55]
- platform: template
name: TV Halterung DOWN
id: tv_down
icon: "mdi:arrow-down-bold-outline"
on_press:
- logger.log: "Button pressed TV Down"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x10,0x11,0x55]
- platform: template
name: TV Halterung Button1
id: tv_button1
icon: "mdi:numeric-1-circle-outline"
on_press:
- logger.log: "Button pressed TV Button1"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x20,0x21,0x55]
- platform: template
name: TV Halterung Button2
id: tv_button2
icon: "mdi:numeric-2-circle-outline"
on_press:
- logger.log: "Button pressed TV Button2"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x08,0x09,0x55]
- platform: template
name: TV Halterung Left
id: tv_left
icon: "mdi:arrow-left-bold-outline"
on_press:
- logger.log: "Button pressed TV Left"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x20,0x21,0x55]
- platform: template
name: TV Halterung Right
id: tv_right
icon: "mdi:arrow-right-bold-outline"
on_press:
- logger.log: "Button pressed TV Right"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x20,0x21,0x55]
- platform: template
name: TV Halterung MEM1
id: tv_mem1
icon: "mdi:alpha-m-circle-outline"
on_press:
- logger.log: "Button pressed TV MEM1"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x01,0x02,0x55]
- platform: template
name: TV Halterung MEM2
id: tv_mem2
icon: "mdi:alpha-m-circle-outline"
on_press:
- logger.log: "Button pressed TV MEM2"
- uart.write: [0xAA,0x06,0x04,0x25,0x03,0xD5,0x00,0x01,0x02,0x55]
Ist das yaml Script dann kompiliert und zum ESP hochgeladen, gibt es ein neues ESPHome Device mit dem Namen TV-Halter in der Homeassistant Umgebung. Hier sind nun die Tasten für die Steuerung als Entitäten gelistet. Hat alles gekplappt, sollte sich die TV-Halterung über den Homeassistant jetzt steuern lassen.
(Es sind noch nicht alles Steuerkommandos richtig implementiert - die korrekten Codes werden in der Tabelle noch ergänzt)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)