Posted by quark007 | Posted in Uncategorized | Posted on 05-08-2023-05-2008
0
Nach vielen Jahren sind bei unserem Roma Gecco Rolltor die ersten Instandsetzungsarbeiten notwendig geworden. Heute früh ist mir beim Rausfahren aufgefallen, dass ein Steil von der Antriebsseite herunterhängt, das vorher nicht da war. Schnelle Analyse: das Seil ist gerissen.
Mir war schon vor einiger Zeit aufgefallen, dass sich an dem Seil die Gewebeummantelung des Seils von der Seele gelöst und an der Umlenkrolle aufgeschoben hat. Es war also absehbar, dass etwas zu tun sein wird.
Nach einigem Stöbern im Internet, bin ich auf ein Thema im Bauexpertenformum aufmerksam geworden. Dort ist eine gute PDF-Anleitung für das Silento Tor verfügbar. Es klang so, als wäre es keine große Schwierigkeit. Challenge accepted.
Doch schon beim ersten Kontakt mit einem Roma-Vertrieb ihn der Nähe kam die Ernüchterung: Austauschseil 50€, 2 Komplette Pakete inkl. Federn etc 350€. In mehreren anderen Foren wurden auch gute Erfahrungen mit einer Reißschnur / Anlasserschnur /Starterseil mit 3.5mm Durchmesser gemeldet also habe ich mir bei Amazon irgendeins entsprechend der Vorgaben und mit guten Bewertungen besorgt (sogar für ~10€ bei 30,5m).
Anleitung nicht für Gecco gedacht
Mir war von Anfang an klar, dass die Anleitung nicht für Gecco Tore gemacht war. Vieles sah aber sehr ähnlich aus. Und das hat sich auch bestätigt.
Einige Anmerkungen die für das Gecco Tor speziell sind (oder mir wichtig sind).
Das Rohr mit der Feder herauszubekommen war sehr einfach. Ich bin mit einer langen Rundfeile in die Tor-Schiene und das Feder-Rohr gegangen und habe mit leichtem Druck an den Rand das Rohr sehr unkompliziert herausbekommen. Leider war die Umlenkrolle nicht mit drin. Also doch den Komplizierteren Weg der Schienen-Demontage gehen.
Idee: Eventuell lohnt der Versuch das Rohr weiter rein zu schieben und damit die Umlenkrolle wieder einzufangen (nicht getestet).
zunächst den End-Anschlag (Position für später markieren), entfernen
Die Verkleidung des Motors abenehmen und den Motor vom Panzer lösen (2 Imbus Schrauben)
Motor hinten aus der Führung entfernen
Den Panzer ganz öffnen. Dann werden vorne, im Winkel 2 Torx Schrauben sichtbar, die entfernt werden müssen (verbinden horizontal-Schiene mit ver vertikal-Schiene + Knick)
Panzer wieder schließen und eine alte Tischdecke / Tuch / Plastikfolie unter das hintere Ende der horizontalen Schiene legen. Die Umlenkrolle rutscht gerne raus und wird dreckig (ungut).
Nun die Befestigungsschraube der horizontal-Schiene lösen und die Schiene nach hinten rausziehen (schon beim Schieflegen, rutscht die Umlenkrolle raus
Die Schritte nach dem Einfädeln einfach wieder rückwärts durchführen und alles ist wieder in bester Ordnung.
Das Einstellen der Feder (anders als vermutet wird die Feder gestaucht und nicht gestreckt) habe ich auch nur nach Gefühl gemacht (meine 2. Seite ist noch in takt).
Mich hat die Prozedur mit einer helfenden Person etwa zwei Stunden (für eine Seite) gekostet.
Die 2. Seite würde sich sicher in 1 Stunde machen lassen. Ich werde berichten, wenn ich das auch erfolgreich ausgeführt habe.
Fazit
Ich hatte arge Bedenken, die rückblickend unbegründet waren.
Mit etwas handwerklichem Geschick, passendem Werkzeug und Geduld, lässt sich ein Seiltausch selber durchführen. Man muss sich aber die Finger schmutzig machen (wollen).
Posted by quark007 | Posted in Uncategorized | Posted on 21-01-2023-05-2008
0
Als Backup für unser Arbeitstier habe ich mir einen gebrauchen S50 bestellt und wollte ihn in unser Gastnetzwerk bringen.
Nach dem Installationsprozess von Valetudo habe ich mich mit dem Wifi AP verbunden und wollte ihn ins Netzwerk hinzufügen. Doch beim speichern der Wifi Daten kommt eine Fehlermeldung, dass der Wifi Key Sonderzeichen (- & und einige andere) enthält und damit nicht gespeichert werden kann.
Doch unser Arbeitstier ist ja in dem Wifi und läuft einwandfrei.
Die erste Idee, ihn temporär in ein Wifi ohne Sonderzeichen zu bringen und nachher über die WebUI die Wifi Einstellungen wieder zu ändern schlug fehl: in der 2023-01 Version kann das Wifi dort nicht mehr geändert werden. Es wird darauf verwiesen das Wifi über die Roboter-Tasten zurückzusetzen und (über den initialen Weg) neu zu verbinden. Aber das ging ja nicht.
Also habe ich mich per SSH auf die Suche nach Wifi Dateien gemacht. Es gibt da mehrere. Die /mnt/data/wlan/wpa_supplicant.conf wird bei jedem Neustart überschrieben (wird wohl aus einer anderen Datei generiert).
Nach ein wenig suchen bin ich auf das Dustbuilder Script gestoßen. Dort ist klar beschrieben, dass die Änderungen in der Datei
/mnt/data/miio/wifi.conf
zu erfolgen haben. Die sah auf meinem Arbeitstier wie folgt aus:
beim heutigen Update meiner PiHole Installation kam es zu folgendem Fehler
package 'php8.0-json' has no installation candidate
DAs ist soweit auch in Ordnung, da PHP8 das JSON Modul mittlerweile mitbringt. Aber die PiHole Installation ist mit PHP7.4 zur Zeit freigegeben (da das auch die unterstützte Version von Debian 10 “Buster”) ist.
Bei mir läuft aber die DietPI Distro und die hat mir PHP8 installiert beim Update.
Es gibt aber eine Möglichkeit zwischen installierten PHP-Versionen zu wechseln. Daher habe ich zunächst wieder PHP7.4 installiert (kann man sich sparen, wenn es noch installiert ist).
Anschließend konnte die Version mit dem folgenden Befehl ausgewählt werden (gefunden hier):
sudo update-alternatives --config php
Im sich zeigen Auswahldialog kann nun die zu aktivierende PHP Version ausgewählt werden. Nach Eingabe der Nummer und bestätigen mit Enter funktioniert das PiHole Update (pihole -up) einwandfrei.
Ob ein nachträgliches Wechseln auf PHP8.0 dann wieder funktioniert, habe ich noch nicht ausprobiert.
Schon vor langer Zeit hatte ich mit den Artikel von Kuketz-Blog vorgenommen und bei meinen Smartphones den Captiveportal Check umgestellt. Doch bei einem Smartphone ging das nicht und ich hatte keine Idee wieso. Egal was ich eingestellt hatte, es wurde immer noch der check auf google/gstatic/android gelaufen ist.
Da mein PiHole ja sowieso läuft und von Hausaus einen Webserver mitbringt, sollte sich das doch lokal einstellen lassen. Seit der neuesten Version von PiHole gibt es auch die Möglichkeit DNSrecords direkt einzugeben. Damit können also die CaptivePortal Adressen direkt auch auf das PiHole selbst geleitet werden ohne umwege über die hosts-datei.
Zunächst habe ich für captiveportal eine eigenen lighttpd vhost angelegt:
Anschließend musste noch die index.php angelegt werden, die nichts anders macht als den Status-Code 204 zurückzugeben.
<?php header("HTTP/1.0 204 No Content"); ?>
Ein Problem gibt es noch: von einigen Android-Versionen wird die folgende URL aufgerufen: connectivitycheck.gstatic.com/generate_204 (ohne Slash am Ende). Anfangs hatte ich versucht über eine 301 Weiterleitung den 204 Status auszugeben, was aber nicht funktioniert hat (da Android für diesen Check der Weiterleitung nicht folgt).
Ich habe mich dafür dann dem mod-rewrite Modul bedient und folgende Regel erstellt:
Dieses Regel-File ist in der Seiten-Konfiguration (siehe oben) schon enthalten (mittels include). Es leitet einfach jede Anfrage auf die index.php um, wenn es die Datei nicht gibt.
Damit erhalte ich nun endlich nicht mehr die nervigen Benachrichtigungen, dass ich mich im Netzwerk anmelden müsste. Das lässt sich auch ganze einfach prüfen, indem im Browser die URL connectivitycheck.gstatic.com/generate_204 (mit und ohne Slash) aufgerufen wird und über die Entwicklerwerkzeuge der Rückgabe-Statuscode geprüft wird. Es darf dort NUR 204 stehen und zu jeder Anfrage auch nur eine Verbindung geben (sonst hätte man wieder die Weiterleitung per 301, die für diesen Zweck nicht funktioniert).
Posted by quark007 | Posted in Computer & IT | Posted on 14-02-2021-05-2008
0
Mein SmartHome ist um einige Rafinessen erweitert worden. Auf Grund des Lockdowns hatte ich mehr Zeit mich mal wieder um was Neues zu kümmern.
Da war zunächst ein gedimmter LED-Streifen als Nachtlicht im Schlafzimmer. Mit einem Wemos D1 mini und einem MOSFET lässt sich über Tasmota der 5V LED Streifen super dimmen und gleichzeitig ins SmartHome integrieren.
Da sowieso bei Ikea etwas bestellt / abgeholt werden sollte, kamen gleich auch noch 2 Tradfri Dimmer ins Haus. Mit diesen sollte sich der LED-Streifen steuern lassen.
Mit Zigbee2MQTT und einem CC2531 ließen sich die Tradfri Geräte super einfach einbinden und per MQTT in OpenHab integrieren (das nervtötende LED Leuchten kann auch deaktiviert werden). Soweit so gut, der Dimmer liefert bei einfachem Druck “On” oder “Off”. Da es ein Dimmer ist, liefert er bei längerem Druck “brightness_up” bzw. “brightness_down” und beim Loslassen “brightness_stop”.
Leider hat Tasmota keine automatische Dimming Funktion (analog Hue), an welches “INCREASE / DECREASE” geschickt werden kann und das Dimmen so lange läuft, bis “STOP” geschickt wird. Daher musste das in OpenHab realisiert werden. Ich habe mich dabei an einem Artikel aus dem Internet orientiert. Meine Regel dazu sieht wie folgt aus:
var Timer DimTimer = null //Timer zum anwenden der nächsten Dimmstufe
var Number DimDir = 0 //Dimm Richtung (+ oder -)
//Rule to simulate dimming to Tasmota device
rule "MFDimmer Dimming Rule"
when
Item MQTT_MFDimmer_Dimming changed to ON
then
DimTimer?.cancel
DimTimer = createTimer(now.plusMillis(10),[|
val Number DimmerState = (MQTT_MFDimmer_brightness.state as Number)
if(DimmerState == 0 || DimmerState == 100 || MQTT_MFDimmer_Dimming.state == OFF)
{
MQTT_MFDimmer_Dimming.sendCommand(OFF)
DimDir = 0
DimTimer?.cancel
}
if(MQTT_MFDimmer_Dimming.state == ON && DimmerState > 0 && DimmerState < 100)
{
MQTT_MFDimmer_brightness.sendCommand(DimmerState + (DimDir * 2))
DimTimer.reschedule(now.plusMillis(500))
//logInfo("MFDimmer Dimming", "Dimming to " + (DimmerState + (DimDir * 2)))
}
])
end
Dazu muss ein Dummy-Switch angelegt werden:
Switch MQTT_MFDimmer_Dimming "Dimming active [%s]" (mqtt)
Sobald nun dieses Item aktiviert wird, wird in 0.5 Sekunden Schritten die Helligkeit jeweils um 2% erhöht bzw. erniedrigt, jenachdem welcher Wert für DimDir beim Tastendruck angegeben wird. Das geschieht hier:
rule "Tradfri Dimmer1"
when
Item z2m_remote_dimmer1_button received update
then
//logInfo("RemoteRuleDimer1", "Tradfri Dimmer1 Input: " + z2m_remote_dimmer1_button.state)
var String RemoteCmd = z2m_remote_dimmer1_button.state
switch (RemoteCmd){
case "on":
{
MQTT_MFDimmer_switch.sendCommand(ON)
MQTT_MFDimmer_switch.postUpdate(ON)
}
case "off":
{
MQTT_MFDimmer_switch.sendCommand(OFF)
MQTT_MFDimmer_switch.postUpdate(OFF)
MQTT_MFDimmer_Dimming.postUpdate(OFF)
DimTimer?.cancel
}
case "brightness_up":
{
if(MQTT_MFDimmer_switch.state == ON) {
MQTT_MFDimmer_Dimming.postUpdate(ON)
DimDir = 1
} else {
zwave_device_[id]_node15_blinds_control.sendCommand(0)
zwave_device_[id]_node15_blinds_control.postUpdate(0)
}
}
case "brightness_down":
{
if(MQTT_MFDimmer_switch.state == ON) {
MQTT_MFDimmer_Dimming.postUpdate(ON)
DimDir = -1
} else {
zwave_device_[id]_node15_blinds_control.sendCommand(100)
zwave_device_[id]_node15_blinds_control.postUpdate(100)
}
}
case "brightness_stop":
{
if(MQTT_MFDimmer_switch.state == ON) {
MQTT_MFDimmer_Dimming.postUpdate(OFF)
DimTimer?.cancel
} else {
zwave_device_[id]_node15_blinds_control.sendCommand("STOP")
zwave_device_[id]_node15_blinds_control.postUpdate("STOP")
}
}
}
end
Dabei ist parallel noch integriert, dass die Rollläden gesteuert werden können, sofern der LED-Streifen nicht angeschaltet ist.
Ich bin mir sicher, dass das auch in Tasmota selber abbildbar ist. Mit Rules geht es aber (soweit ich das überblicken kann) nicht, außer man aktiviert das Math-Paket. Das ist mir jedoch eine ExtraWurst zu viel. Oder aber mit Scripting, was für mich aus dem gleichen Grund ausscheidet.
Für jeden Hinweis, wie ich meine SmartHome Regeln entschlacken kann, bin ich aber sehr dankbar.
Posted by quark007 | Posted in Uncategorized | Posted on 13-08-2020-05-2008
0
Mich hat das Konzept von HackAIR schon lange fasziniert, ich kam jedoch nie dazu es wirklich in Betrieb zu nehmen. Jetzt hat sich die Zeit ergeben und einige dabei zu umschiffende Probleme möchte ich euch gerne mitgeben.
In der Zwischenzeit ist das Projekt hackAIR ausgelaufen. Über die Platform https://opensensemap.org können die Daten aus den hackAIR Sensoren weiterhin abgeliefert werden. Der Code enthält diese option bereits.
Meine Einkaufsliste sieht wie folgt aus:
Wemos D1 mini
Nova SDS011 Sensor
DHT22 Shield
BHM1750 Brightness sensor (geplant zur Steuerung von Rolläden über OpenHab)
Regensensor (geplant zur Steuerung des Mähroboters über OpenHab)
Ich hatte zunächst nur den WEMOS D1 mini und das DHT22-Shield gelötet und verbunden (entsprechend der Anleitung auf der hackAIR webseite). Doch nach uploaden des Projekts konnte nie ein Wert für Luftfeuchte und Temperatur ermittelt werden. Ich ging zunächst von einem Hardware defekt aus, doch da die Dispute-Phase über Aliexpress schon vorbei war, hat mich der Ergeiz gepackt es doch nochmal genauer zu untersuchen.
Über ein Breadboard mit verschiedenen Pin-Anschlüssen hat sich rausgestellt, dass das DHT22 Shield es nicht mag, sowohl über 3,3V als auch über 5V versorgt zu werden.
Lösung: ich habe den 5V Pin einfach abgezwickt und der DHT22 lief. (erstmal, siehe Problem4)
Problem2: Nova SDS011 schläft ein, wacht aber nicht mehr auf
Im hackAIR code steht lediglich die Codezeile:
sensor.turnOn();
Nach einigem Lesen auf mehreren Seiten stellte sich heraus, dass es dem Sensor angeblich genügen würde irgend ein Commando zu bekommen um wieder aufzuwachen.
Nach etwas weiterem Lesen bin ich über diesen Post gestolpert, der etwas anderes behauptet: es ist doch eine konkrete Byte-Folge notwendig, um den Sensor aufzuwecken.
Also habe ich die hackair.cpp in den libraries entsprechend angepasst. Die turnOn(); Funktion sah dann für mich so aus:
void hackAIR::turnOn() {
static const byte WAKECMD[19] = {
0xAA, // head
0xB4, // command id
0x06, // data byte 1
0x01, // data byte 2 (set mode)
0x01, // data byte 3 (wake up)
0x00, // data byte 4
0x00, // data byte 5
0x00, // data byte 6
0x00, // data byte 7
0x00, // data byte 8
0x00, // data byte 9
0x00, // data byte 10
0x00, // data byte 11
0x00, // data byte 12
0x00, // data byte 13
0xFF, // data byte 14 (device id byte 1)
0xFF, // data byte 15 (device id byte 2)
0x06, // checksum
0xAB // tail
};
// SDS011 uses the built-in power saving function
if (_sensorType == SENSOR_SDS011) {
// Send anything to wake up the sensor
//_serial.write(0x01);
for (uint8_t i = 0; i < 19; i++) {
_serial.write(WAKECMD[i]);
}
delay(2000);
} else {
#ifndef ESP8266
digitalWrite(A2, HIGH);
#endif
}
}
Das Projekt neu kompiliert und hochgeladen und siehe da, der SDS011 ist wirklich wieder aufgewacht.
Problem3: Übertragen der Daten per MQTT an OpenHAB
Ein großteil meiner Datensammlung läuft über einen MQTT-Broker (Temperatur und Feuchte Sensoren in jedem Zimmer ; Steuerung des Mähroboters über die LandroidBridge …..). Also sollten auch diese Daten im Smarthome verfügbar sein.
Zunächst war ich der Annahme ich könnte die AdafruitMQTT-Libraries verwenden. Nach viel Rumprobieren hat sich das aber als Fehler herausgestellt. ich habe es nicht geschafft eine Verbindung zu einem normalen Mosquitto Server aufzunehmen. (Offensichtlich ist die Adafruit-Implementierung etwas anders).
Aus meinem Projekt mit den Zimmer-Sensoren habe ich mir Struktur des MQTT-Clients (PubSubClient) übernommen. In auszügen sieht das dann wie folgt aus:
#include <PubSubClient.h> // MQTT CLIENT FOR OPENHAB
// MQTT
#define MQTT_ENABLE "1" // set this to 1 to enable MQTT
#define MQTT_BROKER "192.168.178.XX" // MQTT Broker IP
#define MQTT_USER "openhab" // MQTT user
#define MQTT_PASS "openhab" // MQTT password
[...]
// Create a Wifi client for MQTT connection
WiFiClient espClient; //Only for MQTT
PubSubClient MQTTclient(espClient);
void setup() {
// MQTT Initialisation
MQTTclient.setServer(MQTT_BROKER, 1883);
[....]
}
void loop() {
[...]
//DHT READ
float env_temp = dht.readTemperature();
float env_hum = dht.readHumidity();
// Send error message if DHT22 values could not be read
if(isnan(env_hum) || isnan(env_temp)){
Serial.print("Temp: ");
Serial.print(env_temp);
Serial.print(" | Hum: ");
Serial.println(env_hum);
MQTTreconnect();
MQTTclient.publish("tele/hackair/state", "ERROR Temp/Hum");
}
[...]
if (MQTT_ENABLE == "1") {
if (!MQTTclient.connected()) {
MQTTreconnect();
}
String dataMQTT = "{\"data\":{\"PM25\":\""; // PM25 ist eingfacher über openhab abzurufen als PM2.5
dataMQTT += data.pm25;
dataMQTT += "\",\"PM10\":\"";
dataMQTT += data.pm10;
dataMQTT += "\",\"temp\":\"";
dataMQTT += env_temp;
dataMQTT += "\",\"hum\":\"";
dataMQTT += env_hum;
// dataMQTT += "\",\"rain_d\":\""; //noch nicht implementiert
// dataMQTT += env_rain_d; //noch nicht implementiert
// dataMQTT += "\",\"rain_a\":\""; //noch nicht implementiert
// dataMQTT += env_rain_a; //noch nicht implementiert
// dataMQTT += "\",\"lux\":\""; //noch nicht implementiert
// dataMQTT += env_lux; //noch nicht implementiert
dataMQTT += "\"},\"battery\":\"";
dataMQTT += vdd;
dataMQTT += "\",\"tamper\":\"";
dataMQTT += "0";
dataMQTT += "\",\"error\":\"";
dataMQTT += data.error;
dataMQTT += "\"}";
if (MQTTclient.publish("tele/hackair/SENSOR", (char*) dataMQTT.c_str()) && DEBUG == "1") {
Serial.print("MQTT Publish successful: ");
Serial.println(dataMQTT);
} else if (DEBUG == "1") {
Serial.print("MQTT Publish failed");
Serial.println(MQTTclient.state());
}
}
[...]
// define functions
void MQTTreconnect() {
// Loop until we're reconnected
while (!MQTTclient.connected()) {
Serial.print("Attempting MQTT connection...");
// Create a random client ID
String clientId = "Hackair-";
clientId += String(random(0xffff), HEX);
// Attempt to connect
if (MQTTclient.connect(clientId.c_str(), MQTT_USER, MQTT_PASS)) {
Serial.println(" connected");
MQTTclient.publish("tele/hackair/LWT", "Online", false); //ohne hat er die Verbindung nicht behalten.
} else {
Serial.print("failed, rc=");
Serial.print(MQTTclient.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
MQTTclient.loop();
}
Mit ein wenig Konfiguration in openHAB sieht das Ergebnis dann wie folgt aus:
Problem4: Instabiler Neustart des Wemos D1 mini
Beim Neustart des Wemos D1 mini kommt es wiederholt (schon fast regelmäßig) vor, dass entweder die Ausgabe über die Serielle Schnittstelle nicht funktioniert oder aber das Auslesen der DHT22 Messwerte. Diese liefern dann nur nan zurück und somit ist eine Feuchtigkeits-Korrektur der Partikelmessung nicht mehr möglich.
Nach einem Upload eines Sketches auf den ESP funktioniert die Serielle Ausgabe ohne Neustart, jedoch der DHT22 nicht.
Nach dem ersten hard reset (Strom trennen und wieder verbinden) geht fast immer die Serielle Schnittstelle nicht.
Nach einem weiteren hard reset geht ab und an das Auslesen der DHT-Werte schief. Egal wie oft die Reset-Taste am ESP gedrückt wird.
Eine Lösung für das DHT22 Problem konnte ich hier finden: https://blog.zs64.net/2018/02/fixing-the-wemos-d1-mini-dht22-shield/ Es hat sich gezeigt, dass der D4-Port, den das DHT22 Shield verwendet, auch für die LED-Steuerung verwendet wird. Beim Start kann es also dazu kommen dass sich Sensor-Initialisieren und LED-Steuern in die Quere kommen.
Übers Breadboard mit umlegen auf den D3-Pin läuft es nun stabil wie nie!!! Damit hatte ich dann auch deutlich weniger Probleme mit einer nicht funktionierenden Seriellen Verbindung.
Edit: beim Programmieren eines weiteren DHT22 Shields kam ich wieder nicht weiter. Sowohl das umlegen des D-Pins, als auch der Spannungsversorgungs-hack hat nicht geholfen. Nach viel googlen bin ich dem Problem auf den Grund gekommen: die DHT-Library funktioniert mit meinen DHT22 nur bis Version 1.2.0. Mit allen neueren geht es nicht (hier der Bug-Eintrag dazu).
Gehäuse
Damit alles schön verpackt in den Außenbereich kann, habe ich nach einem Gehäuse gesucht. Auf thingivers.com bin ich bei der “Dust Sensor Box” fündig geworden. Auf meinem Ender3 habe ich das ganze aus weißem PLA mit 15% Infill gedruckt (195°C Düse und 48°C Druckbett Temperatur).
Da das Projekt aber für einen Nodemcu v2 amica vorgesehen ist, habe ich den Wemos D1 mit dem DHT22 Shield einfach reingelegt. Durch die relativ geringe Höhe und den leicht abstehenden DHT22 Sensor klemmt das ganze eigentlich ganz gut.
Montiert wurde die Box anschließend unter den selbstgebauten Hochbeeten (an der Querverbindung zur Stabilisierung des Mörtelwannenbodens).
Datenübertragung an opensensemap und luftdaten.info
Zusätzlich zu dem bereits unterstützten opensensemap.org wollte ich auch luftdaten.info mit einbinden. Dazu gibt es schon ein Script. Das habe ich als Vorlage verwendet, um den Code von hackair entsprechend anzupassen.
Es hat sich bei mir noch ein anderes Problem gezeigt: auch auf opensensemap konnten die Daten nicht hochgeladen werden. Nach viel herumprobieren und optimieren des Codes bin ich zu der im Code befindlichen Lösung gekommen.
Es kommt bei mir öfter vor, dass HackAIR an irgend einem Punkt hängen bleibt. Er macht dann nicht weiter und liefert auch keine Werte. Ich habe die Vermutung, dass es in der SDS011 ein Problem gibt. Die Serielle Schnittstelle so lange angeschlossen zu lassen, schaffe ich nicht (hackAIR hängt unter einem Hochbeet auf der Terasse). Daher habeich mich damit abgefunden und über openHAB eine Regel erstellt, die den Strom 20 Sekunden trennt und danach wieder anschaltet.
Posted by quark007 | Posted in Uncategorized | Posted on 15-03-2020-05-2008
0
Nach langem Zögern habe ich mich doch entschieden meinen Robi mit einer Custom-Firmware füttern. Insbesondere die Xiaomi App hat mich mit den ganzen Verbindungen nach China genervt.
Schon länger hatte ich die Dustcloud entdeckt, jedoch nie zum Laufen bekommen. Bei der Suche dazu, bin ich über Valetudo gestolpert. Nach viel lesen dazu, habe ich mich entschieden es zu probieren.
Die Anleitung basiert auf einem Linux System. Zum Glück habe ich gerade mein altes Netbook mit Linux Mint aufgesetzt.
Installation
Die Anleitung dazu ist nicht sonderlich ausführlich aber voll ausreichend.
Direkt anschließend habe ich wie in den FAQ beschrieben noch die Sprachdatei installiert (das geht aber auch über die Valetudo WebUI).
Der Web über die WebUI funktioniert, war mir aber nicht bequem genug. Im Wiki gibt’s auch einen Artikel zur Homeassistant Integration. So habe ich den Robi direkt in openHAB eingebunden. Die thing Definition sieht bei mir so aus (eigens aus den MQTT-Nachrichten erstellt):
Thing topic valetudo "MQTT Roborock S50" @ "Indoor" { Channels: Type string : state "Status" [ stateTopic="valetudo/rockrobo/state", transformationPattern="JSONPATH:$.state" ] Type number : battery "Battery" [ stateTopic="valetudo/rockrobo/state", transformationPattern="JSONPATH:$.battery_level" ] Type string : speed "Fan Speed" [ stateTopic="valetudo/rockrobo/state", commandTopic="valetudo/rockrobo/set_fan_speed", transformationPattern="JSONPATH:$.fan_speed" ] Type number : cleanTime "Clean Time" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanTime" ] Type number : cleanArea "Clean Area" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanArea" ] Type number : cleanCount "Clean Count" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.cleanCount" ] Type number : wareMain "Verschleiss Hauptbürste" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.mainBrush" ] Type number : wareSide "Verschleiss Seitbürste" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.sideBrush" ] Type number : wareFilter "Verschleiss Filter" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.filter" ] Type number : wareSensor "Verschleiss Sensoren" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.sensor" ] Type string : state2 "Status 2" [ stateTopic="valetudo/rockrobo/attributes", transformationPattern="JSONPATH:$.state" ] Type string : lastRun "LastRun" [ stateTopic="valetudo/rockrobo/attributes" ] Type string : command "Command" [ stateTopic="valetudo/rockrobo/state", commandTopic="valetudo/rockrobo/command", transformationPattern="JSONPATH:$.state" ] }
Das Problem mit der Karte ist aber geblieben: die gibt es nur über die WebUI. Da die Map Daten auch über mqtt übertragen werden, kann man von einem extra Server eine PNG Karte erstellen lassen. Das Projekt dazu nennt sich ICantBelieveItsNotValetudo.
Nach clonen, installieren und konfigurieren lief alles auf Anhieb. Nun noch den Server als Dienst registrieren:
Die Datei /lib/systemd/system/valetudo-map.service erstellen und folgenden Inhalt einfügen:
[Unit] Description=valetudo map service Documentation=https://github.com/weweave/landroid-bridge After=network.target
Zugegeben, ich bin etwas blau-äugig an die Sache heran gegangen. Ich dachte mit ein wenig Erfahrung im Löten, mit RF433 Spielereien auf den GPIO des RaspberryPi wäre ich einigermaßen ausgestattet. Im Endeffekt hat es super geklappt, aber ich kam mir nie sicher vor, was ich machen (beim Flashen). Eigentlich ist es aber auch gar nicht so schwer, wenn man den Weg kennt. Daher hier eine kurze Anleitung (die englische allgemeine Version gibt es hier und Infos zu dem Obi-Stecker hier).
USB UART TTL 3.3V Converter/Programmer (e.g. CP2102, CH340G, FT232, PL2303)
Schraubenzieher (Kreuzschlitz und 3-fach Kreutschlitz)
Steckverbinderleiste (altenativ Chip-Sockel mit langen Pins) oder Kabel zum fest-anlöten
ev. ein 3.3V Netzgerät
Damit kann es losgehen
1. Vorbereiten des Steckers
Mit dem 3-Flügel Schraubenzieher die beiden Schrauben am Gehäuse öffnen. Anschließend mit einem leichten Drucke die Gehäuse-Ober- von der Unterseite abnehmen und mit einem Kreuzschlitzschraubenzieher die Platine vom Gehäuse lösen. Anschließend kann man die Platine vorsichtig, dass keine Kabel abreißen oder Elektronikbauteile beschädigt werden, herausnehmen. Dann sieht man auch schon wunderbar die Lötstellen für unsere Steckerleiste.
Wie man lötet brauche ich hoffentlich nicht erklären. Nun lötet man 7 Steckstifte an die entsprechenden Kontakte. Da man die Lötstelle schlecht einsehen kann, ist dies eine schöne Fehlerquelle, falls das Flashen nicht klappt. Dann nochmal nachlöten.
2. Vorbereiten der Firmware
Zunächst Arduino IDE herunterladen. Anschließend in ein Verzeichnis entpacken und vor dem ersten Start direkt dort einen neuen Ordner mit dem Namen “portable” anlegen. Damit arbeitet Arduino IDE automatisch immer in seinem eigenen Ordner (User-unabhängig). Nun kann Arduino IDE gestartet werden. Wir müssen ihm nun alle Infos zu dem ESP8266 beibringen. Dazu auf “File->Preferences” / “Datei->Voreinstellungen” gehen und in “Additional Bookmarks Manager URLs” folgende Quelle einfügen (ich habe zusätzlich die Sprache auf Englisch umgestellt um mit den GitHub Angaben arbeiten zu können) und mit “ok” bestätigen.
Dann gehen wir auf “Tools->Board->Boardmanager” und suchen in der Liste den ESP8266 und installieren die neueste Version. Danach wählen wir unter “Tools->Board” den ESP8266 aus. Die Einstellungen sollten wie auf dem Bild aussehen. Wichtig ist noch der Com-Port. Der muss auf die Nummer eures UART-TTL-Boards eingestellt werden (kann man im Gerätemanager nachschauen).
Arudino IDE schließen. Von GitHub die neueste Tasmota-Firmware herunterladen und in den “portable/sketchbook/” Ordner entpacken. Anschließend aus dem Tasmota Ordner den Inhalt des Lib-Ordners in “portable/sketchbook/libraries” verschieben.
Nun öffnet Arduino IDE wieder und wählt über File/Datei das Sketchbook “Sonoff” aus. Über den Pfeil ganz rechts die Datei “user_config.h” auswählen. Darin folgende Änderungen vornehmen und speichern:
– CFG_HOLDER auf den heutigen Tag setzen (z.B. 0x20180318)
– WiFi Gateway, DNS,
– Wlan SSID und Key (macht das konfigurieren einfacher, wenn das Gerät direkt im WLan ist)
– Wenn man möchte kann man auch gleich den MQTT Zugang konfigueren (funktioniert über die Web-Oberfläche am Ende aber auch sehr gut)
Mit “Sketch -> Verify/Compile” die Firmware einmal kompilieren und prüfen ob alle Abhängigkeiten erfüllt sind.
3. Vorbereiten und Flashen der Hardware
Vor dem ersten Einstecken des UART-TTL die Treiber von der Hersteller Homepage herunterladen und installieren. Anschließend einstecken und zunächst mit einem Multimeter prüfen, ob zwischen dem 3.3V Pin und Ground wirklich nur 3.3V anliegen (sonst geht der ESP ganz schnell kaputt).
Jetzt verbinden wir UART-TTL und die Wifi-Steckdose. Manchmal, wenn das Flashen nicht funktioniert, kann man probieren RXD und TXD auf einer Seite zu tauschen (bei neuen Sonoffs ist das manchmal der Fall).
UART Obi-Steckdose
3.3V VCC
RXD TXD
TXD RXD
GND GND
Den 3.3V Pin am UART lasse ich erst einmal nicht verbunden (Überspannung beim Anstecken). Um den ESP in den Flash-Modus zu bekommen, müssen wir den GPIO0 mit GND kurzschließen (entweder mit einem extra GPIO-Kabel oder einfach mit einem Krokodilklemmen-Kabel). Jetzt den 3.3V Pin anschließen und nach 2-5 Sekunden wieder entfernen (die blaue LED leuchtet dann ganz leicht).
Jetzt installieren wir die neue Firmware über “Sketch -> Upload”. Ist der Upload bei 100% ohne Fehler durchgelaufen, trennen wir die Spannung wieder (ziehen den Stecker also vom UART ab). Bei mir tauchte beim Upload anfangs öfter ein Fehler auf, dass der Sync nicht funktioniert hat. Bei mir war das ein Kontakt-Problem der Stiftleiste durchs löten. Nocheinmal erwärmt und neues Lötzinn hat Abhilfe geschaffen.
Als nächstes ändern wir in der user_config.h den CFG_HOLDER zurück auf “0x20161209” und flaschen das ganze nochmal (natürlich wieder im Flash-Modus). Das Vorgehen ist dabei das gleiche wie eben.
Wenn das alles ohne Fehler funktioniert hat, schließen wir die 3.3V wieder an, diesmal nicht im Flash-Modus. Jetzt kann man im Router nach der IP-Adresse Ausschau halten. Diese ruft man dann im Browser auf und kann alles weitere konfigurieren.
4. Steckdose konfigurieren
In der Oberfläche (siehe Bild) geht man auf “Configuration” und “Configure Modul”. Dort wählt man “18 Generic” aus und klickt auf “Save”. Das Modul startet neu und man geht nochmal auf die gleiche Konfigurations-Seite. Dort muss man dann folgende Einstellungen vornehmen:
Nocheinmal speichern und den 3.3V Pin wieder trennen.
Von jetzt an kann man den Stecker direkt in eine Schuko-Steckdose stecken und betreiben. Einstellungen kann man auch jetzt immernoch vornehmen.
5. Einbinden in OpenHAB2 über MQTT
Für das Einbinden in OpenHAB braucht man erstmal einen Mosquitto (MQTT)-Server. Den kann man auf dem gleichen Gerät installieren wie openHAB auch. Wichtig ist, dass man einen Anmeldenamen und ein Passwort für den Server vergibt. Die sind bei Tasmota nämlich Pflicht (wäre auch blöd, wenn irgendjemand einfach alle MQTT-Geräte steuern könnte). Eventuell die Firewall prüfen, dass Verbindungen auch erlaubt sind.
In OpenHAB nun das MQTT Plugin installieren. In dem Conf-Ordner unter “services” die mqtt.cfg entsprechend eures MQTT-Servers anpassen. Es hilft hier OpenHAB einmal neu zu starten. Jetzt kann man die Items für die Steckdose anlegen. Ich habe mich zunächst auf das An-Aus-Schalten beschränkt. Dafür in einer .items-Datei folgende Zeile anlegen:
Nach einiger Zeit habe ich mein altes RaspberryPi mit OSMC-Installation herausgekramt. Eigentlich nur um mein 433MHz Sender-Modul zu testen. Beim Anschließen, hat allerdings das WLan nicht funktioniert. Das hat mich gefuchst und ich habe versucht es neu einzurichten.
Ich hatte in der Zwischenzeit mein WPA2-Key geändert, da einige Geräte mit einem “=” in der Passphrase nicht klar kamen. Also habe ich versucht es über die Oberfläche von OSMC zu ändern. Doch das schlug immer fehl (Ich weiß nicht ob es an Fehlern der Eingabe oder an einem falschen Tastatur-Layout gelegen hat).
Nachdem Login per SSH (im LAN) habe ich versucht es über Connman mit dem WLan zu verbinden (wie hier beschrieben). Doch es hat nicht geklappt. Keine Meldung, dass die Verbindung korrekt hergestellt werden konnte.
Nach dem Connect kam keine Abfrage des WPA-Keys. Eine neue Verbindung mit meinem Gast-WLan hat jedoch funktioniert wie beschrieben.
Ich habe dann rausgefunden, dass in dem Ordner /var/lib/connmann/ die Configurationen der einzelnen Verbindungen gespeichert wurden. Dort habe ich den Ordner meines WLans gelöscht und das ganze nochmal über die connmanctl probiert: es hat geklappt:
Wie oft ist es schon vorgekommen, dass ich einfach schnell z.B. alle Dateien in einem Ordner als Text-File versenden wollte. Dann fängt jedes mal die Suche nach dem richtigen Skript wieder von vorne an. Daher möchte ich hier eine kleine Sammlung aller meiner verwendeten Scripte anlegen. Vielleicht hilft es ja auch dem ein oder anderen weiter.
@echo off
FOR /r %%V IN (*.pdf) DO FOR /F "tokens=1-5 delims=./: " %%J IN ("%%~tV") DO IF EXIST "%%L-%%K-%%J %%M-%%N%%~xV" (ECHO rename "%%V" "%%L-%%K-%%J %%M-%%N_1%%~xV" & rename "%%V" "%%L-%%K-%%J %%M-%%N%%~xV") ELSE (rename "%%V" "%%L-%%K-%%J %%M-%%N%%~xV")
pause
Bildschirmhelligkeit festlegen Win10DE (hier für EN)
@echo OFF
for /f "tokens=*" %%i in ('powercfg -q ^| find "GUID des Energieschemas"') do set pwrSchm=%%i
set pwrSchm=%pwrSchm:~25,38%
for /f "tokens=*" %%i in ('powercfg -q ^| find "(Bildschirm)"') do set dsply=%%i
set dsply=%dsply:~22,36%
for /f "tokens=*" %%i in ('powercfg -q ^| find "(Bildschirmhelligkeit)"') do set brtnss=%%i
set brtnss=%brtnss:~29,37%
Echo Bildschirmhelligkeit von 0-100% eingeben
set /P brightness= % brightness: %=%
powercfg -SetDcValueIndex %pwrSchm% %dsply% %brtnss% %brightness%
powercfg -S %pwrSchm%
Aktuell wird der zu setztende Wert abgefragt. Soll es jedoch ein fester Wert sein, dann in der Zeile “set /P brightness=” alles dahinter löschen und einen fixen Prozentwert 0-100 einsetzen