Entwicklungen

Jetzt spendiere ich der Software doch einen eigenen Punkt. Bei den diversen Setups gibt es schon informationen, hier die letzten dazu.

Probleme gab es mit volllaufendem Speicher - da habe ich auf alte Version zurückgesetzt (mehr dazu und im forum). Aktuell versuche ich es mal wieder mit der aktuellsten. In der Nightly Version wäre MQTT dabei, aber es soll erst mal wieder stabil laufen. Ich habe also alles neu aufgesetzt.

Um dem Fehler auf die Spur zu kommen, pilight wie folgt gestartet: sudo gdb –args pilight-daemon -D (da kommt zwar ein Fehler, aber in der gdb dann „start“ eingeben, und er läuft los. Wie wenn man mit Schmerzen zum Zahnarzt geht, und die Schmerzen weg sind, wenn man dort ist - Pilight lief 2 Tage ohne Probleme durch…also nichts mit Debuggen.

MQTT geht erst im Nightly-Build, den ich (noch) nicht eingespielt habe.

Um die Socket API nutzen zu können, muss man entweder das Beispiel von GitHub nutzen, oder selber etwas Programmieren. Vor allem dann, wenn man pilight als standalone laufen lässt. Dann am besten auch in der config den „port“: #### setzen. Leider habe ich das mit dem blocking und timeout nicht verstanden. Der Socket blockierte nie. Bei einem normalen restart von pilight beendete sich der Socket mit der Ausgabe „1“. Wenn ich pilight per kill-9 beende, bringt der Socket lauter 0 Byte lange Ergebnisse. Kein timeout, kein blocken, egal was ich einstelle. Frage jetzt genau auf diese Situationen ab, mache 10 Sekunden Pause und versuche dann wieder einen Socket-Connect. Aktuell habe ich allerdings keine Verwendung dafür. Vielleicht mal Fenster auf/zu darüber in die DB schreiben.

Der Aufruf des GUI über die Webserver API und dann an den URL /values oder /config danach nutze ich, um den aktuellen Stand der Fenster und Steckdosen abzufragen.

Das Schalten von Licht und Steckdosen über wie Web-API funktioniert auch ganz gut.

Nutzt man pilight standalone (config.json), muss man darauf achten bei den Aufrufen von pilight-send Server und Port mit anzugeben, da dann von pilight kein ssdp Dienst mehr zur Verfügung gestellt wird.

Es gibt ein Device Programm. Dort wollte ich den Rolladen steuern, da der nicht mit einem selbstgebastelten Funk-C-Programm hoch und runter gefahren wird. Weder der direkte Aufruf des C-Programms, noch über eine Shell hat funktioniert. Die Shell macht nichts anderes, als so lange zu laufen, wie der Rolladen unten ist, damit pilight den Prozess findet und als 'aktiv' anzeigt. Aus Frust rufe ich aus pilight jetzt einen Node-Webservice auf, der die Shell aufruft. Wieso das geht, ist mir ein Rätsel.

Leider kann man einzelne Protokolle nicht deaktivieren, dazu müsste man neu kompilieren. Nachdem ich nur kerui, kaku_dimmer und brennenstuhl benutze, habe ich in den seufzen mal nach den werten gesucht und versuche, in der config.json die werte entsprechend anzupassen, das wären dann „mingaplen“:9316, „maxgaplen“:10880, „minrawlen“:50, „maxrawlen“:148 (original:4420,72900,26,400)

Ich habe jetzt die neuen Werte eingetragen, und seitdem auch weniger, eigentlich bisher keine, Abstürze mehr erlebt.

433 MHz prefilter - V 3.0

Wiring manual@pilight

Gekauft habe ich eine Developer-Edition mit USB-Anschluss. Das Schaltbild und weitere Infos gibt es hier. Das sollte alles einfacher machen. In Arduino unter Einstellungen bei Boardmanagern folgendes eintragen

http://digistump.com/package_digistump_index.json

In Werkzeuge→Board …→Boardverwalter nach „Digistump AVR Boards“ suchen und installieren. Dann das Default-Board auswählen. Wichtig: Nicht einstecken, bis Arduino dich auffordert! Sonst kommt die Meldung

Running Digispark Uploader...
Plug in device now... (will timeout in 60 seconds)
Assertion failed: (res >= 4), function micronucleus_connect, file library/micronucleus_lib.c, line 100.
> Please plug in the device ... 
> Press CTRL+C to terminate the program.

Es hat auch geholfen, alle USB-Devices (und leere Kabel) abzuziehen. Aus der Anleitung: Digispark only shows up as a programmable device for 5 seconds, after that it will start running its code (when it is new and un-programmed this means it will blink) and disappear or act like the USB device you programmed it to act like.]

Da ich den attiny unter macOS programmiere, brauche ich wahrscheinlich nur 5V;GND;433MHz-in und Raspberry/Pilight-in; das macht es einfacher, da bei mir die Pins SCK/RST 23/24 sowieso belegt sind und ich kein .avrduderc File anlegen wollte.

Leider auch hier eine Niederlage: Sowohl bei der Originalsoftware v3, als auch bei dem neueren v4 habe ich es nur soweit hinbekommen, dass minütlich die Version gesendet wurde (3 mal überlegt, und dann zuerst doch die beiden Daten-Kabel falsch herum angeschlossen). Vom RF-Empfänger wurde aber nichts weiter geleitet, egal was ich eingestellt habe. Alos vielleicht doch mal von Raspberry aus Flashen?

auf dieser Seite steht: install pilight firmware:

sudo apt-get install pilight-firmware

Mit gestartetem pilight und „pilight-receive -S 127.0.0.1 -P 5555“ kam - immer pilight restart machen!

{
	"message": {
		"version": 3.00,
		"lpf": 40,
		"hpf": 16000
	},
	"origin": "receiver",
	"protocol": "pilight_firmware",
	"uuid": "0000-b8-27-eb-61c45c",
	"repeats": 1
}

und mit der 4er Version:

{
	"message": {
		"version": 404.00,
		"lpf": 150,
		"hpf": 16000
	},
	"origin": "receiver",
	"protocol": "pilight_firmware",
	"uuid": "0000-b8-27-eb-61c45c",
	"repeats": 1
}

Alles geht - bis auf die KERUI-Fenster - da muss ich mir die Längen und das Coding anschauen seufz Stand März 2021