@anon98227572 Wenn du so lange Artikel zitierst, gib doch bitte eine Quelle an. Noch besser: Artikel verlinken, und nur die wichtigsten Teile zitieren. Es sollte immer deutlich zu erkennen sein, welche Inhalte von einem selbst stammen, und welche von woanders kopiert sind.
Die Moderation dankt 
4 „Gefällt mir“
geen Punkt 
tot ziens
1 „Gefällt mir“
Stimmt,habs halt gleich ins deutsche umgesetzt,wollt es gleich lesbar hier haben.
Hallo weedmichnicht,
Es freut mich das du auch zu diesem thread gefunden hast, ich fühle mich sogar geehrt von dir, dass du mir die Fehlermeldungen auseinander dröselst, diese Meldung habe ich dazu geschrieben, da ich vorher grünes Licht gegeben habe.
Mit ulimit -n kann zu Beispiel ermittelt werden wv Dateien geöffnet wurden und mit nano die Datei /etc/sysctl.conf öffnen und bei fs.file-max wunschfile deklarieren.
Na, wahrscheinlich, weil es den Index nicht gibt. Wenn du eine Datei liest und in dieser seeken (glaube so nannte man das) willst, dann musst du vorher durch alle Zeilen iterieren („for … in“ Python, „for(…)“ bzw „for-each(…)“ Java, C Sprache, etc). So erfährst du wieviele Zeilen die Datei enthält und erhältst damit den maximalen erlaubten Index, den du der Funktion übermitteln darfst.
Um den background zu liefern:
Es wird eine Datei ausgelesen, die in ein array gelesen, die wird gesplittet nach Trennzeichen, danach wird an Stelle x mehrere Zeichen eingelesen diese convertiert. Aber ab einer 1 bis 1 Tag ist plötzlich die Datei anders… Bzw mein array leer und den Index gibt es nicht mehr und dieses Verhalten wirft Fragen auf…
Weedmichnicht, danke für deine Hilfe, aber ich denke es liegt daran wie ich die Dateien öffne und schließe und ich hatte jetzt etwas Zeit und probiere eine neue einlesemethode. Vl kann ich ja in 2 Tagen wieder Entwarnung geben.
Viele Grüße
Barlec
1 „Gefällt mir“
Btw: wenn du ein Text von einem Post markierst, erscheint dann ein graues Feld „Zitat“ - damit kannst du im Editor beliebig zitieren. 
Ähh, wie meinst das? Du hast das doch auf GitHub hochgeladen, wenn ich hier iwo richtig gelesen habe. Schick mir einfach Link, Datei und in welcher Zeile… vielleicht finde ich ja die Ursache.
Das sollte man eigentlich easy & günstig mit den standard Raspberry Pi Sensor realisieren können: Hier geht’s zum Sensor…
Den Sensor installierst einfach in der Innenseite ganz oben in der Growbox. Dadurch kannst die Entfernung zwischen Sensor und Pflanze bestimmen. Der Benutzer muss nur die Höhe der Box messen und ggf. die Höhe des Topfes, um die eindeutige Höhe der Pflanze zu bestimmen. Allerdings musst dann pro Pflanze ein Sensor benutzen. Naja gut, je mehr du von den Sensoren (über den Link) kaufst, umso weniger musst sogar zahlen.
1 „Gefällt mir“
Wenn du gewartet hättest, bis es hochgeladen wäre, könnten wir es sehen. 
1 „Gefällt mir“
Sag mal heute stimmt irgendwas net. Bin wohl etwas worres um de schnorres:joy:
Aber den Ansatz mit dem Schallsensor verfolge ich schon bin mal gespannt ob er zuverlässig genug ist.
1 „Gefällt mir“
Danke für den Hinweis. Ich werde darauf achten. Sorry
Jop der Code ist auf github, es ist der Ds18D20 Sensor in der Funktion grad_lesen().
Müsste in der Zeile 26 sein, while zeilen[0].strip()[-3]!= ‚YES‘
Hehe, ja, dann passt das ja. ^^
Brauche noch den Link zu deinem Git Repos. 
Bitteschön hier ist mein spaghetti code repo.
Ich denke du weißt wie man damit umgeht 
Zum workflow:
SensorCreateUI.py ist das momentane anlegetool.
HydroPy.sql sind die sql statements die man zu beginn Durch jagen muss.
WatchDog.py ist die Überwachung.
Fehler tritt auf wenn der WatchDog zu schnell durchläuft. Dort ist momentan der timer 60 sec. Wenn du ihn auf 1 sec stellst tritt der Fehler sehr schnell auf.
https://github.com/Barlec/PiGrow
Ich könnte halt prüfen ob die Datei leer ist und wenn, kurz warten neu laden. Ich fürchte das System hat kurz Zugriff drauf… Hat dann nix in der var und bricht ab.
Aber das wuerde die Durchlauf Geschwindigkeit mindern. Was dafur spricht meine Prüfung innerhalb des WatchDog asynchron zu gestalten. Habe momentan schon Probleme mit Verzögerung. Da ich auf den dht manchmal warten muss, da sonst keine Daten geliefert werden.
Zur WatchDog.py:
Wenn das crasht, vermute ich wird es daran liegen, dass du den Sensoren nicht so schnell Werte übergeben kannst. (Was auch immer genau „.writeValue()“ tut)
Zur DS18D20.py:
Das macht irgendwie keinen Sinn…
self.sensordir = self.SYSTEMPATH + self.SYSTEMID + „/w1_slave“
… später…
datei = open(self.sensordir, „r“)
… du versuchst also aus einen Pfad bzw halt einen Ordner Zeilen zu lesen?
[EDIT] Ahh, okay, „.strip()“ gibt eine Liste aus, die alle Teilstrings des Strings beinhaltet, ohne Leerzeichen.
1 „Gefällt mir“
Systempath wird aus der Datenbank geholt.
Systemid ist die Id die der sensor bekommt wenn er sich per w1 Protokoll am System anmeldet. Da dies ein Bus system ist, bekommt er eine Nummer, dann hat jeder Bus die Datei w1_slave.
In der Datei steht eine in hex codierte Adresse, crc und dann ein YES. Darunter ist eine weitere Adresse und t=wertsensor
Der muss gelesen werden.
Bsp:
(Hier lese ich gerade life den sensor aus und gebe mir den Inhalt zurück.)
Und jo musste path heißen.
In ‚writeValue‘ lese ich den sensor mit der sensor eigenen Funktion die Werte und schreibe sie in die Datenbank. Das ist der einheitsname der trigger Funktion. Greift aber Dann ja auf die Funktions der classe zurück.
Aber hab gerade TCL installiert. Da ich die funktion einfach ersetzt habe und nach 15 min nen Fehler wegen TCL hatte aber danach bis jetzt kein Fehler läuft seit 20 min… Teuteuteu @WeedMichNicht
UPDATE Hotpatch
Guten Tag alle zusammen,
Ich habe bezüglich dieses Projektes noch einige Hausaufgaben zu erledigen.
Videos,
Einkauf,
Weiterentwicklung.
Ziel dieses Monates ist es die GUI zu entwickeln und dem Actiondaemon Leben einzuhauchen, zumindest was das anlegen von relays betrifft.
Leider konnte man die letzte zeit nichts von mir hören, das lag daran das ich in meinem stillen kämmerchen ein par Gedankengänge und tests durchspielen.
Meine Pläne zu github. Ich werde dort 2 stände einspielen quasi einen neuen branch anlegen der heißt Entwicklung. In diesem Stand werden zukünftig alle nicht wirklich getesteten Codes hochgeladen.
Unter main wird nur noch code hochgeladen der mindestens eine Woche ohne Probleme lief.
Gibt es da vl Einwände? Oder Tipps wie ich das Verfahren zu updaten verbessern kann? Ich möchte keinem den Stand kaputt machen durch nicht ausreichend geprüfte Updates.
Der Code auf github wurde vor 12 Tagen geupdatet, darin enthalten sind die Hotpatches:
Error 1: too many open files (hier könnte ich nachhelfen in dem ich erlaube mehr files zu öffnen) FIXED
Error 2: can’t open file (hier hat ein timer geholfen, dies wurde provoziert da wir den timer auf 5 secunden gesenkt haben) FIXED
Error 3: can’t find array index (hier kenn ich nicht das eigentliche problem… FIXED
Habt einen schönen Tag und ich freue mich immer wieder über euer Engagement.
Bis demnächst euer
B4rl33c
4 „Gefällt mir“
Guten Tag zusammen,
es ist etwas her, das ich hier noch was schrieb. Es ist viel Zeit vergangen. Leider ist dieses Projekt wie es war eingemottet worden. Der Webentwickler abgesprungen und ich saß noch da mit einem Haufen kleiner Bugs und einem Runtimefehler der immer nach 2 Wochen auftat.
ALSO WURDE DAS PROJEKT EINGESTAMPFT
Doch kampflos wollte ich das Feld nicht räumen. So entstand ein kleinprojekt.
Was möchte ich mit meiner Software erreichen?
Ich möchte nun einen Controller zur Verfügung stellen der auf Abfragen basiert.
Bsp: Wenn Sensor ID TEMP > 5 TODO Relay ID switchOff
oder: AB Zeit ALLE zeit secunden TODO SensorID readValue
dadurch wäre es möglich einige Sachen bedingt anzusteuern. Die oben genannten Beispiele sind bereits etabliert. Es sollen noch Multivalues dazu kommen sowie Multitodos, so das mehrere Values als Trigger gesetzt werden können sowie mehrere Aktionen bei einem Auslöser. Wird umgesetzt sobald alle Sensoren umgesetzt wurden. Solange müssen wir mit singel trigger Funktionen klar kommen =).
Die bisher vorkommenden Sensoren sind wie die oben genannten:
SOIL Capa
DHT_11
MQ_2
Relays 5v 220v
Ds18d20
PH Sensor E201-BNC
TDS Keystudio V1.0
Waage Sensor (Bezeichnung Unbekannt aus einer waage ausgebaut^^)
Was hat sich geändert?
Es gibt nun 2 Clients einmal AGEND_MANAGER und den AGEND_WORKER. Beide sind Webservices geschrieben in Python mit Flask. Der AGEND_WORKER ist nur ein executiver Client der die angeforderten Werte dem AGEND_MANAGER schickt, dieser Prüft und Koordiniert die Tasks. Auslösende Timeevent werden vom MANAGER ausgelöst. Dazu beherbergt der MANAGER die Datenhaltung. So gibt es nur noch ein Client der schreiben und lesen darf.
Dieses Konstrukt erlaubt es clients zu verwenden die etwas schwächer sind wie die Raspi4.
Noch eins ich werde versuchen Schaltpläne zu fertigen… ich versuche es…
Wie kommt man zum Projekt?
Das Projekt selbst gibt es auf GitHub:
Ihr könnt es auspacken und am besten auf einen Pi 4 mit 8gb zu ziehen, als grundsystem ist rasbian zu empfehlen. Ich nutze ein 64 bit System. Das Projekt im /home/user/ Verzeichnis entpacken, damit später auch die Pfade passen. Wenn ich alle oben gelisteten Sensoren fertig implementiert habe und diese auch mit der Software funktionieren werde ich euch ein Image zur Verfügung stellen. Danach führt ihr die Grundinstallationen der notwendigen Packete durch (hoffe keins vergessen zu haben und wenn doch BITTE melden):
sudo pip install pymysql
#############################
ALL
#############################
sudo apt update;
pip install -U Flask
#############################
Installs für WORKER
#############################
apt
sudo apt install libgpiod2
Pip
sudo pip3 install adafruit-circuitpython-dht;
#############################
Installs für MANAGER
#############################
#apt
sudo apt install mariadb-server
#pip
sudo pip3 install mysqlx
sudo pip install escape
Nach diesen Installationen sollte der PI nun bereit sein für den ersten Sensor.
Ich empfehle erst mal einen DHT_11 Sensor. Wenn Ihr diesen verkabelt habt, müsst ihr diesen in der Datenbank anlegen. Dazu legt Ihr einen AGEND in der mysql tabelle an. Ruft mit shift + t das Terminal auf und gibt ein sudo mysql -u root und entert.
Danach muss die Datenbank erstellt werden:
–Löschen aller Configs:
DROP USER ‚GrowUser‘@‚localhost‘;
DROP DATABASE GrowPy;
– Erstellen der Datenbank GrowPy
CREATE DATABASE GrowPy;
– wechsle Datenbank
USE GrowPy;
– Erstellt einen USer GrowPy
CREATE USER ‚GrowUser‘@‚localhost‘ IDENTIFIED BY ‚r00t!‘;
– Gibt ihm die Rechte Select, Insert, Update (ALL) to ALL Databases and Tables
GRANT ALL PRIVILEGES ON * . * TO ‚GrowUser‘@‚localhost‘;
–Create 0
CREATE TABLE Agends(
piid INT(3) NOT NULL AUTO_INCREMENT PRIMARY KEY,
piAgend VARCHAR(10),
port INT(10),
networkIP VARCHAR(32),
active BOOLEAN
);
CREATE TABLE Devices(
deviceID INT(6) NOT NULL AUTO_INCREMENT PRIMARY KEY,
deviceType VARCHAR(160),
piid INT,
deviceName VARCHAR(160),
deviceComment VARCHAR(380),
FOREIGN KEY (piid)REFERENCES Agends(piid)
ON DELETE CASCADE
ON UPDATE CASCADE
);
–Create SensorTable
CREATE TABLE SensorMQ (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID)
ON DELETE CASCADE
ON UPDATE CASCADE,
analogPin INT(2),
resistance INT,
ro_clean_air_factor INT,
calibration_sample_times INT,
calibration_sample_interval INT,
read_sample_interval INT,
read_sample_times INT
);
CREATE TABLE SensorSOIL (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE,
channel INT,
spi INT,
wert_high INT,
wert_low INT,
calibrated BOOLEAN,
lastCalibration TIMESTAMP
);
CREATE TABLE SensorDS18D20 (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE,
systemID VARCHAR(20),
systempath VARCHAR(120)
);
CREATE TABLE SensorDHT (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE,
vers INT,
gpioPin INT
);
–SensorWerte Tabelle für alle Sensorwerte
CREATE TABLE SensorWerte (
timeStamp TIMESTAMP,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE,
value FLOAT(8),
physical_unit VARCHAR(6),
unittype VARCHAR(10)
);
CREATE TABLE RELAY (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
deviceID INT,
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE,
gpioPin INT,
switchState BOOLEAN,
status BOOLEAN
);
–INTERACTION TABLE FÜR TIMEBASED AND VALUEBASED OR MULTIVALUEBASED
CREATE TABLE TodoTable (
id INT PRIMARY KEY,
deviceID INT,
action VARCHAR(10),
actioncomment VARCHAR(160),
FOREIGN KEY (deviceID)REFERENCES Devices(deviceID) ON DELETE CASCADE
ON UPDATE CASCADE
);
CREATE TABLE TimeBasedInteraction (
id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
todoid INT,
lasttime TIMESTAMP,
intervall INT(10),
FOREIGN KEY (todoid)REFERENCES TodoTable(id)
ON DELETE CASCADE
ON UPDATE CASCADE
);
CREATE TABLE ValueBasedInteraction (
id INT(16) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
isValueType VARCHAR(4),
bySensorID INT,
isValue BOOLEAN,
todoid INT,
oprt CHAR,
FOREIGN KEY (todoid)REFERENCES TodoTable(id)
ON DELETE CASCADE
ON UPDATE CASCADE,
FOREIGN KEY (bySensorID)REFERENCES Devices(deviceID)
ON DELETE CASCADE
ON UPDATE CASCADE
);
So nun sollte es die Datenbank GrowPy geben, schaut nach ihr mit dem comand „SHOW DATABASES;“, nun sollte mitgeteilt werden das ihr diese schon benutzt oder angezeigt werden. Falls ihr noch nicht die Datenbank verwendet nutzt „USER GrowPy;“ um die DB zu verwenden. Nun kann der erste Agend angelgt werden, der den ersten Sensor erhält. Dazu die Zeile eintippen:
– Anlegen Worker
INSERT INTO Agends(piid,piagend,port,networkIP,active)VALUES(1,„WORKER“,8448,„localhost“,true);
Damit legt ihr einen woker mit der piid 1 an und dem port 8448 also standart mit dem wert True als aktiver client.
so nun das device:
– Anlegen des Devices DHT_11
INSERT INTO Devices(deviceID,piid,deviceName,deviceType,deviceComment)VALUES(1,1,„Luftsensor DHT“,„DHT_11“, „Allgemeine Luftfeuchte“);
Es wird die DeviceID kennung für Sensor festgelegt sowie die piid des agend der ihn ausführt.
– Configs für DHT_11
INSERT INTO SensorDHT(deviceID,vers,gpioPin)VALUES(1,11,25);
Hiermit werden die Konfigs des DHT festgelegt, welche version und welcher gpio pin.
Nun noch das Zeit basierte Intervall Interaction festlegen und ein Todo, dies sind actionen mit einem ausslösenden intervall von x Secunden und einer festen Startzeit.
– Eintrag TODO was zu tun
INSERT INTO TodoTable(id,deviceID,action,actioncomment)VALUES(1,1,‚readValue‘,„DHT_11 Sensor lesen alle 60 Secunden“);
– Eintrag in die Zeit Basierte Intervall Tabelle
INSERT INTO TimeBasedInteraction(lasttime, intervall,todoid)VALUES(NULL,60,1);
Diese Eintragung lässt einen sensor DHT_1 mit der DeviceID 1 alle 60 Secunden lesen.
schaut bitte einmal unter den config/config.conf nach ob ihr da was anpassen müsst, an sich ist dort alles für einen 1- 2 py betrieb ausgelegt. Bitte nicht die Ports anpassen.
Start des Clients im auszuführenden Verzeichnis ein run app.py ausführen oder python3 app.py einmal im TestManager und einmal im Slave Verzeichnis.
Start und Reihenfolge, als erstes sollte der Manager gestartet werden, dann der Worker. Wenn es nun funktioniert, glückwunsch, dann habt ihr jetzt ein etwas funky wirkede Wetterstation^^
Spass bei seite ich hoffe nun alle 2 wochen ein update machen zu können.
ich wünsche euch einen schönen tag und ein baldiges wochenende
2 „Gefällt mir“
Schade dass das Projekt den Weg so vieler schöner Projekte gegangen ist 
Wir haben schon ne ganze Menge angefangener Raspi/Arduino-Threads hier …
Umso cooler, dass du weitermachst 
wünsche viel Erfolg, und vielleicht finden sich ja auch wieder ein paar Mitstreiter 
2 „Gefällt mir“
Guten Tag Zusammen,
heute wieder live aus der Softwareschmiede xD
Mir ist da was im Konstrukt aufgefallen, das mich etwas nervt aber vl findet ihr das garnicht mal so schlimm.
Ich möchte ja mit meiner Software Querys abarbeiten zmB durch die TimeBasedInteractions. Diese sind durch ein Intervall konfigurierbar. ZmB. nehmen wir an wir möchten ab einer gewissen zeit (START_TIME) einen Wert einlesen (ACTION_TYPE=readValue) an einem DHT_11 Sensor mit der DeviceID 1 in einem Intervall von 60 Sekunden (INTERVALL=60s), dann ist sehr einfach möglich. Nun möchte ich zmb eine Lampe einschalten und nach 12 Stunden wieder aus. Dazu dachte ich EASY kann ja den gleichen algorythmus verwenden.
Also zum Beispiel werden dazu zwei querys konfiguriert:
1Q: zum Anschalten
START_TIME=2022-04-03 00:00:00 INTERVALL = 24h ACTION_TYPE = switchOn
2Q: zum Ausschalten
START_TIME=2022-04-03 12:00:00 INTERVALL = 24h ACTION_TYPE = switchOff
Ergebnis:
Das Licht geht an, das licht geht vl aus, aber wahrscheinlich bleibt es an…
Warum? Da sich hier zwei Zustände um 12 Uhr überschneiden…
ich habe es mit einem Intervall von 2 minuten getestet.
So nun kann ich zwei Lösungen anbieten:
Lösung 1 Quick and Dirty:
einfach bei der zweiten Ausschaltung die Zeit um eine Sekunde verschieben. (könnte später die UI übernehmen)
Lösung 2 Einführung von TimeBasedInteraction_ByToTime:
Diese neue klasse implementiert einen Trigger bei Zeit für den Start einer Aktion und eine Endzeit für eine Aktion bei jeden dieser zeit kann ein Todo festgelegt werden.
Das wäre die Klassische Zeitschaltung 12:55 switchOn device 1 , 19:55 switchOff device1
Lösung 3 Dirty?!:
Hier wird einfach der State on überschrieben. Es wird dafür gesorgt, das der switchOff befehl immer als letztes gesendet wird wodurch immer auch ausgeschaltet wird.
Hm ich bin irgendwie unentschieden Punkto 2 soll eh mal kommen aber bis dahin, weis ich nicht wie ich es lösen soll und ob es überhaupt schlimm ist…
Das Git (aktueller Branch ist der Develop):
https://github.com/Barlec/GrowPy.git
1 „Gefällt mir“
Guten Tag Zusammen,
wieder gibt es Neuigkeiten. Es wird gerade an der Version 2 gebaut des GrowPy. Dabei wurde das Interaction Design neu überdacht. Es wird eine GUI eingeführt, diese wird wahrscheinlich in zwei Monaten veröffentlicht (vage Behauptung). Bis dahin werde ich noch an dem Backend arbeiten. Die Idee für den Intelligenten Stromkasten (Stromsteuerung über pi im Verteilerkasten mit Relays Strommesser und Dimmer & ) wird noch etwas warten müssen, dafür werden demnächst wifi Steckdosen unterstützt jedoch nur solche mit fester SSID.
Es wird nun möglich sein mehrere PIs als Slaves dem Master unter zu ordnen, dadurch können die Ressourcen besser genutzt werden. Dem Master wird ein Backend hinzugefügt für die Verwaltung der GUI. Es wird möglich sein dieses zu trennen um sie zumbeispiel extern auf einem Server laufen zu lassen. Des weiteren wurden die Konfigurationsfiles überarbeitet… Sowie die Datenbank. Die neue Version wird nicht kompertible sein zur alten. Aber denke das beunruhigt euch weniger^^
Was oder warum ist der LINK zum GIT verschwunden?
Ja das Git wurde entfernt und wird wieder ab der Version 2 Verfügbar sein. Auch wieder unter gleichem Synonym, jedoch befinde ich mich gerade in einem Entwicklungsstatus in dem ich keine Abgabe bauen möchte. Auserdem bin ich noch von einem Komplettsystem weg und finde es als nicht würdig ein system zur verfügung zu stellen das noch über sql zu verwalten ist^^ Da wird jetzt auf die GUI gewartet sie wird KOMMEN das freut mich soooooo…
ASO wenn jemand die aktuelle version will einfach immer melden auch wenn gerade keine auf git is kann ich sie private rausrücken.
Viele Grüße Eurer B4rl33c
1 „Gefällt mir“
Growland Status
Einen schönen guten Tag wünsche ich allen lesenden.
Heute möchte ich euch einmal zeigen wie weit meine Fortschritte bei dem Projekt Growpi ist. Ich habe mich dazu entschlossen das Projekt etwas umzubennen.
Aktuell habe ich an diesen Komponenten des GrowLand gearbeitet:
Growpi - Controller
Growpi - Agend
Growpi - Ui
Die Komponenten:
Ds18d20
Dht22
Relay
Soilcapa Sensor (aktuell nur mit selbst konfiguriertem Verzeichnispfad)
MQ2
Sind aktuell integriert.
An folgen Integrationen wird gearbeitet:
Waage Sensoren
433MHZ WLAN Steckdosen
Große Integrationen (die dauern noch):
Dimmer
Spannungsreichster
Der Growpiagend wurde auf die neue Version des Growpicontrolers angepasst.
Damit passen nun Schnittstellen.
Der growpi agend wurde um syscalls erweitert die die Einbindung neuer Sensoren erleichtern soll.
Die Datenbanken wurden erweitert dahingehend wurde der growcontroler nun angepasst.
Nun werden auch die Werte von den Relais in der sensorwerte Tabelle gespeichert dies ermöglicht später differenzierte trigger zu setzen.
Growpiui
Dies ist eine komplette neu Entwicklung.
Nicht sehr schön tut aber was sie tun soll.
Um diese nutzen zu können muss ein growpicontroler existieren, dieser fungiert als datenbasis.
Über die growpiui können nun Agends angelegt werden, mit Name Comment, ip, Port und optional eine mac Adresse.
Nach dem anlegen eines Agends kann dem agend devices hinzugefügt werden (devices sind Sensoren und ext Geräte).
Bei dem erstellen eines devices muss festgelegt werden welcher Sensor ist angeschlossen, wie ist der Name, Kommentar und wie wurde dieser angeschlossen (gpio pin oder Pfad).
Nach dem anlegen von Devices kann über die eventbar Events verwaltet werden.
Einem Event liegen trigger zu Grunde und Aktionen. Ein Event funktioniert so, das die trigger überprüft werden, ist die Überprüfung der trigger True so werden die Aktionen ausgeführt.
Die trigger können über den LogicOperator verknüpft werden. Hier wäre ein AND eine Verknüpfung das beide trigger True sein müssen damit die Aktion ausgeführt wird.
Ist der trigger mit OR verknüpft, muss nur ein trigger True sein.
Ist der Schalter invers gesetzt, so wird im Falle das die Aktion vom Typ Action ist diese invertiert durchgeführt switchOn → switchoff sobald die Prüfung der trigger False ergibt.
Trigger unterscheiden sich in zwei grundtypen: (value,time )
Value:
Prüfen von values die in der ValueQuery landen. Diese können auf Gröser kleiner gleich einem Wert an einem festgelegten physischen Value am device festgelegt werden.
Time:
Time enthält eine Startzeit, mit dieser wird das Event getriggert und der timetrigger ist für diese Abfrage True.
Die Endzeit invertiert für die Ausführung die Aktionen vom Typ Action (damit lässt sich dann das Licht an und ausschalten).
Dabei ist zu beachten das beim erreichen der Endzeit nur der timetrigger zählt und dabei die Aktionen invertiert.
Timeshift legt fest um wieviele Secunden die Start und Endaktion nach Ausführung verschoben werden soll.
Wie gehts nun weiter?
Ich werde noch etwas an der gui api arbeiten so das dass anlegen und löschen zuversichtlich funktioniert.
Dann die zwei Änderung 433hz WLAN Steckdose und waagesensor und der ui und Controller sowie agend konfigurieren.
Danach werde ich hier wieder einen link zum Git posten. Dann wäre die Version im Alpha Stadium.
Ich hoffe das passiert nun die nächsten 2 Monate…
Wenn die Grundkonstellation passt, könnte man überlegen auch über die 433 hz Schnittstelle Sensoren auszulesen. Sowie die Anbindung von ardinos sowie die Umsetzung von Sicherheitsmechanismen.
Wenn jemand Lust hat eine ui zu schreiben, die die bisherige ersetzt , dann meldet euch gerne bei mir!
Hier die Ansichten:
Moin,
erstmal, geiles Projekt!
Ich habe auch schon überlegt, einige Sachen zu automatisieren. Habe einen kleinen Unraid-Server am Laufen und möchte es darin implementieren.
Ich bin noch neuer in der Informatik und in einer Umschulung zu Fachinformatiker für Anwendungsentwicklung und denke, es wäre ein cooles Projekt. Als Erstes will ich versuchen, die Lüftung je nach Temp und Feuchtigkeit zu regulieren.
Gruß
Psy
1 „Gefällt mir“