Plugwise ohne Server direkt auslesen/schalten

Hi Axel, hier noch zwei Auffälligkeiten:

Wenn man wie von dir vorgeschlagen fürs WF einen Link auf den jeweiligen Circle macht und dann mit Klick auf „State“ zu schalten, dann muß die Variable „State“ das Script „PW_Controller“ als Actionscript hinterlegt haben.
Denke das sollte noch ins Setup rein.

Weiters ist der Aufruf:

$idCatCircles = CreateCategory("Circles",IPS_GetParent($IPS_SELF),0);

in Zeile 7 etwas ungeschickt, da der IPS Installer seinen Output ins WF zurückschreibt.
Entweder im IPS installer in der Funkton „Create Category“ das Print bla bla bla
auskommentieren, oder die PW_Controller ein bisl umbauen.

Schicke dir später mal eine Vorschlag, muß jetzt kurz weg.
Achja, zum loggen des Gesamtverbrauch hätt ich auch 1-2 Vorschläge, kommt heute Abend.

gruß
bb

Hallo Bernhard,

danke für die beiden Hinweise zur Installation, hab ich bereits in der Anleitung korrigiert.

Das Actionscript in der State Variable sollte durch das Skript gesetzt sein. War das bei dir nicht der Fall?

Der CreateCategory-Aufruf schreibt bei mir nur ins Log, nicht ins WebFront. Versteh nicht was du meinst.

Grüsse, Axel

Hi Axel

  • meine kleine Tochter hat Besuch bekommen, nun darf Papi wieder an IPS :slight_smile:

Nein, bei den State Variablen ist bei mir nirgends ein Actionscript hinterlegt.

Wenn „State“ vom Webfront betätigt wird, dann schreibt das Create Category seine Meldung ins Webfront. Die muß man dann dort erst bestätigen.

Wenn die Zeile
$idCatCircles = CreateCategory(„Circles“,IPS_GetParent($IPS_SELF),0);

nur bei Case „Execure“ und Case „Registervariable“ drin ist, dann ists gut.

gruß
bb

Hi Bernhard,

schön, dass du dabei bist - IPS-mässig halbwegs fit ist ja nur ganz leicht untertrieben :stuck_out_tongue:

Ich habe deine Anmerkungen versucht nachzustellen, eine komplett neue Struktur aufgebaut und kann die Punkte trotzdem nicht nachvollziehen. Weder WF, noch iFront melden beim schalten etwas (die Kategorie wird ja beim allerersten Aufruf des Skripts angelegt!) und das Actionskript wird bei mir richtig hinterlegt. Benutzt du die neusten Skripte in version 0.4 von gestern?

Wenn du Zeit hast, dann bau deine Ideen doch ein und veröffentliche dass als Version 0.5.

Deine Ideen bzgl. Gesamtverbrauch würden mich sehr interessieren. Ich erwäge schon die Werte in separate DB auszulagern, bspw. sqlite.

Danke & Gruß,
Axel

Hi
merkwürdige Sache das mit dem Setup. Ich werd mal schauen, vieleicht liegts an meiner IPS_Installer. Die hab ich schon ewig nicht mehr upgedated.

Dann hätt ich da noch folgende Patches:

					case "00D8":  //eingeschaltet
		 				// print "Eingeschaltet MAC".substr($buf,12,16);
						$myCat = IPS_GetObjectIDByIdent(substr($buf,12,16), $idCatCircles);
						SetValue(IPS_GetVariableIDByName ("State", $myCat),True);
// begin by bb
			       	$ID_Watt_before_Off = GetValue(IPS_GetVariableIDByName('Watt_before_off',$myCat));
					   SetValue(IPS_GetVariableIDByName('Watt',$myCat),$ID_Watt_before_Off);
// end by bb
						// Sofort Verbrauch abfragen
						// PW_SendCommand(substr($buf,12,16));

						break;

					case "00DE":  //ausgeschaltet
						// print "Ausgeschaltet MAC".substr($buf,12,16);
						$myCat = IPS_GetObjectIDByIdent(substr($buf,12,16), $idCatCircles);
						SetValue(IPS_GetVariableIDByName ("State", $myCat),False);
// by bb
		            SetValue(IPS_GetVariableIDByName ("Watt", $myCat),0);

						// Sofort Verbrauch abfragen
						// PW_SendCommand(substr($buf,12,16));

						break;

und


					// Aktueller Verbrauch in Watt ermitteln
					$value 	= hexdec($pulse)/8; ///8;
					$out 		= (pow(($value+$offNoise),2)*$gainB)+(($value+$offNoise)*$gainA)+$offTotal;
					$watt 	= (($out ) / 468.9385193)*1000;
					$watt 	= round($watt,0);

					SetValueFloat(CreateVariable("Watt", 2, $myCat, 0, "~Watt.3680", 0), $watt);

// begin by bb
					If ($watt > 1) {
						SetValueFloat(CreateVariable("Watt_before_off", 2, $myCat, 0,"", 0), $watt);
						IPS_SetHidden(IPS_GetVariableIDByName ("Watt_before_off", $myCat),True);
// end by bb
					};

		

legt eine Dummy Variable an welche beim schalten übers Webfront die Variable „Watt“ sofort updated.
Ist nicht wirklich wichtig, kommt aber optisch besser.

Wegen Gesamtverbrauch könnte es Sinn machen bei der aktuellen Pulseauswertung zu bleiben. Ich denke diese etwas aufzufriesieren dürfte leichter sein als mit der komplizierten PW internen Berechnung zu hantieren.

Ich stelle mir vor die Auswertung vom PW_Controller Script zu entkoppeln.
–> gut für die Laufzeit !
Das neue Script benützt dann fürs WF den jetztigen 1min Raster. - exakte Genauigkeit is da ja nicht so unbedingt wichtig.

Fürs Datenbanklogging gibts zb. einen 10min Raster welcher durch die längere Integrationszeit dann auch bessere Genauigkeit bringen sollte.
Siehe auch die Spec der Circles.
Da kann dann evtl. auch Tages/Monats/Jahres Auswertung und Kostenberechnung mit rein. Gleich wie in Andres 1Wire S0 Script.

Für Spezialfälle zb.- „Energieprofil der Waschmaschine“ erstellen" könnte man dann auch noch einen extrakurzen Raster bauen welcher permanent pollt aber dafür nur ein Gerät verarbeitet.

Das ganze dann noch mit exakten Timestamps verrechnet (Genauigkeit!!) und netten Highcharts sollte ganz gut kommen.

gruß
bb

– ich muß gleich noch ein Paket Circles bestellen. Das Zeug kommt echt gut.

Ach nochwas,

  • heut bin ich ganz pingelig:
			// PRINT IPS_GetName($myCat)." - Pulses Neu: ".$newPulses.", Alt: ".$oldPulses.", Delta: ".$delta.", kWh: ".$kWh."
";

					SetValueFloat(CreateVariable("Pulses Stunde", 2, $myCat, 0, "", 0), $newPulses);
					$oldGesamtverbrauch = GetValue(IPS_GetVariableIDByName("Gesamtvebrauch", $myCat));
               SetValueFloat(CreateVariable("Gesamtvebrauch", 2, $myCat, 0, "~Electricity", 0), $oldGesamtverbrauch + $kWh);
 					// PRINT IPS_GetName($myCat)." - Gesamtverbrauch Neu: ".$oldGesamtverbrauch + $delta.", Alt: ".$oldGesamtverbrauch.", Delta: ".$delta;

				}
				break;

beim Anlegen der Variable „Gesamtverbrauch“ fehlt ein „r“

greez
bb

Für den Gesamtverbrauch könnte ich mir auch vorstellen, dass der nur stündlich in die Datenbank abgelegt wird. Trigger dafür wäre der std. Gesamtpulse. Wenn der kleiner als sein Vorgänger ist, dann ist eine Stunde rum.

Bzgl. der Watt-Zahlen und Waschmaschinenmelder mache ich mir keine Sorgen. Meine fallen tatsächlich zuverlässig unter ein Grenzwert, sind also mit Bordmitteln auswertbar. Sonst halt vollständig loggen und durch separates Skript alle Werte älter als 24 Stunden löschen oder so.

LOL, also Typo R in Gesamtverbrauch ist in Version 0.5 gelöst. Siehe Original-Post

Ich meinte eher den Zähler über eine längere Zeit aufzusummieren und erst dann die Arbeit (kWh) zu berechnen.
Dadurch verringert sich die Ungenauigkeiten zb durch Signal und Scriptlaufzeit.

Ich werde mal versuchen was zu basteln. Mal sehen ob sich ein Unterschied ergibt.

Ach ja, das fehlende „r“ gibts öfter im Script.

Korrekterweise müßte die Beizeichnung für „Watt“ auch nicht sondern zb. „aktuelle Leistungsaufnahme“ sein. Watt ist ja die Einheit.

gruß
bb

Hi Bernhard,

Danke für dein Input. Das r ist natürlich überall angepasst, Variable Watt habe ich jetzt in Leistung und State in Status umbenannt. Neue Skripte im Original-Post.

Das Thema Gesamtverbrauch ist kompliziert. Die Circles antworten mit 0013 auf die Anfrage 0012 mit der aktuellen Leistung und dem Verbrauch in „Pulses“ seit Stundenbeginn. Im Skript wird der Wert in „Pulses Stunde“ gespeichert. Nach einer vollen Stunde legen die Circles das in den internen Buffer, der mit 0048 und der LogAdresse abgelesen werden kann. Die aktuellste LogAdresse wird mit dem Status-Befehl (0023/0024) mitgesendet.

Die Abfrage des Buffers klappt schon und könnte bspw. bei Änderung der LogAdresse getriggert werden und einem Zähler hinzuaddiert werden. Mit dem Nachteil, das der IPS-Zähler dann immer eine Stunde hinterherhinken würde.

Der aktuelle Ansatz im Skript aktualisiert den Zähler quasi minütlich - schaut besser aus, erzeugt aber eine Menge Daten.

Ich überlege mir echt, ob ich die Uhr der Circles nicht eine Minute vorstelle, so dass die Circles schon den Verbrauch im Buffer haben und dieser in IPS der richtigen Stunde zugewiesen wird.

Buffer hätte halt auch den Vorteil, dass wenn IPS aus welchen Gründen auch immer nicht loggen kann, der Verbrauch auch im Nachinein erfasst werden könnte.

Danke & Gruß, Axel

Ach verstehe, zugegeben so genau hab ich mich ins PW Protokoll noch nicht eingelesen.

Wennst die Genauigkeit erhöhen willst ist es meiner Meinung nach wichtig den Timestamp wann die „Pulse Stunde“ aggregiert wurde abzulegen und beim nächsten Run dann für die Berechnung mitzuverwenden.

Schau mal die Zeiten an, wann die Variablen geschrieben werden, paar Sekunden
Auf oder Ab sind da immer Abweichung.
Hab zzt. nur 5 Circle aktiv aber die Zeitintervalle in denen „Pulse Stunde“ upgedated wird schwankt um 3-4 Sekunden.
Muß ja wohl durchs ZigBee so sein.

Aktuell rechnest aber so als ob das Intervall immer genau 60sek wäre.

Bleibt zwar immer noch die Ungenauigkeit der Signallaufzeit vom Circle zu IPS, aber immerhin, eine Varianz wäre dann raus.

Dein Vorschlag die interen Uhr vorzustellen kann ich jetzt nicht wirklich folgen was das für die Abfrage des Gesamverbrauchs ausm Circle bringt.
Muß da aber auch noch ein wenig lesen.

gruß
bb

Wenn ichs richtig verstehe hat die aktuelle Methode also auch zu jeder vollen Stunde ein Problem. Denke da gehen auch ein paar Pulse verloren. Noch dazu je mehr je länger das Abfrageintervall ist. Hmm. Blöde Sache.

Einen Befehl um die Pulse UND die Circle Uhrzeit in einem Datenpaket auszulesen gibts nicht ?

gruß und gute Nacht
bb

So, jetzt fällt mir da nochwas auf.

zzt. berechnest du den Gesamtverbrauch ja viel zu kompliziert.
Du rechnest ja zwei mal die Differenz aus und summierst das dann auf.
d.h. Fehler aus Laufzeitunterschieden summieren sich.

Einfacher: Man weiß der Circle stellt den Pulszähler jede volle Stunde auf Null. Richtig ?
Vorausgesetzt die Uhren stimmen überein kann man ja innerhalb einer Stunde zu jedem beliebigen Zeitpunkt die bis dahin angefallenen Pulse auslesen und mit den Sekunden der aktuellen Stunde in kWh umrechnen.
Somit sollte es innerhalb einer Stunde immer sehr genau sein.
Damit kann man das Logging je nach Bedarf genau einstellen.

Kurz nach jeder vollen Stunde zusätzlich den vom Circle selbst aufsummierten Gesamtverbrauch der letzten Stunde.
Zählt man nun beides zusammen so müßte das doch passen.
Oder hab ich da was übersehen.

Is schon ein bisl spät, vieleicht isses ja Blödsinn…

jetzt aber wirklich gute Nacht
bb

Hi Bernhard, Respekt wie schnell du dich ins Thema einarbeitest.

Also die aktuelle Ermittlung des Gesamtverbrauchs ist eine Krücke, ungenau und produziert eine hohe Datenmenge.

Besser wäre das Auslesen des Buffers. Wenn man den aber einer IPS-Variable hinzurechnet, dann geht das systembedingt nur so, dass der Verbrauch nicht der richtigen Stunde zugeordnet wird (da Buffer erst nach voller Stunde zur Verfügung steht und IPS nicht erlaubt historische Werte zu loggen).

Deshalb wäre ein Workaround, die interne Uhr der Circles ein Paar Minuten vorzustellen, so dass der Verbrauch in IPS wenigstens der richtigen Stunde zugeordnet wird. Trigger für das Auslesen des Buffers wäre Änderung der LogAddress. Damit würde man volle Genauigkeit erreichen und trotzdem geringe Laufzeiten, geringe Datenmengen und wenig Hilfsvariablen. Nachteil wäre halt, dass man - wie die Originalsoftware Source - nur in Stunden misst. Genauere Analyse und Verbrauchsprofile können über die akt. Leistung erfolgen. Die Variable kann minütlich geloggt werden und Daten nach ein Paar Tagen gelöscht werden.

Was haltet ihr von dem Ansatz?

Morgen Axel
Ich verstehe es immer noch nicht warum es notwendig sein soll die Circle Uhr zu verstellen.
Rechne doch mal: Angenommen der Stundenverbrauch wird in den ersten 10sec nach der vollen Stunde ausgelesen, so ist der „Fehler“ doch nur maximal 0.27%. bzw. nicht der Fehler aber der Wert würde um ein paar sec. versetzt in die Datenbank geschrieben.
Würde man also aus der Datenbank auf den Wert zur vollen Stunde zurückrechnen wollen hätte man eben maximal diese 0.27% als Fehler.
So what ?

Die in IPS (Webfront) angezeigte Summe kann aus aufsumierten Circle-Stundenwerten + den innerhalb der aktuellen Stunde in kurzen zb. Minute ermitteltem Wert dargestellt werden.
Damit hat man hier schnelle UND genaue Rückmeldung.
Welche jede Stunde mit dem Circle abgeglichen wird.

Auf diese Summenmvariable dann einen Trigger legen und sie in eine andere zu loggende Variable umkopieren. Damit kann man dann in zb. 10min Abständen loggen und müllt die Datenbank nicht voll.

  • Ach wie schön wäre es wenns meine geliebte RRD Datenbank noch geben würde. Die wäre genau der richtige Fall für diese Aufgabe. -

Der Fehler ist immer noch kleiner als die Grundgenauigkeit des Circle.-

Um ihn klein zu halten könnte man je nach Gusto täglich/monatlich/jährlich auf Null stellen.

gruß
bb

Hi Bernhard,

das umkopieren macht die Sache aber doch nur noch komplexer und evtl. nicht mehr allgemeingültig für jeden nutzbar.

Anyway, zur Verdeutlichung: aktuell werden im Skript die Pulses pro Stunde minütlich geloggt und aus dem Delta der Gesamtverbrauch errechnet. Nicht nur bei Dauerläufern (wie bspw. ständig durchlaufendem Server), sondern auch bei quasi allen anderen eingeschalteten Circles werden demnach 2460365 = 525.600(!) Wert pro Jahr in die DB geschrieben. Und das wie gesagt pro Circle! Meine 18 Circle würden dann knapp 9 Mio Datensätze pro Jahr generieren.

Bei stündlichem Messintervall wären es dagegen nur 8760 pro Circle.

Bei Nutzung der IPS-eingebauten Datenbank ist aber das nachträglich verdichten der Daten nicht möglich und es können Daten nur mit dem aktuellen Zeitstempel geloggt werden.

Um die Werte trotzdem IPS-konform abzulegen daher die Idee, die Circles durch vorstellen der Uhr den Stundenverbrauch einfach ein Paar Minuten früher in den Buffer zu schreiben. Skript zum (ver-)stellen der Uhrzeit hab ich bereits.

Jannis, wuppi und die anderen: was haltet ihr davon?

Danke & Gruß, Axel

P.S.:
Schau mal in die Access-Datenbank „Plugwise.mdb“ (irgendwo unter c:\Users), das hilft für das Verständnis der internen Verbrauchsmessung der Circles (LogAdress, Buffer…) ungemein.

Danke & Gruß, Axel

Naja, das wäre proCircle ein 1 Zeiler Script + Timer.
Dafür kann jeder sein eigenes log Intervall noch dazu für jeden Circle getrennt einstellen.
Das hat doch was.

Na klar, das wäre Unsinn. Will ich ja auch gar nicht, siehe oben.

Im übrigen glaube ich mal gelesen zu haben das nur Änderungen in die DB geschrieben werden. d.h. wenn sich der Wert nicht ändert wird auch nix geschrieben.
Wenn man also die Auflösung veringert kann man für Dauerläufer die Datenmenge ganz drastisch reduzieren.
Müßte man aber nochmals bei Paresy nachfragen, hab das nur dunkel in Erinnerung.

Ich kann ja heute Abend mal versuchen meine Variante umzusetzen, mal sehen wie weit ich komme.

Verstehe mich bitte nicht falsch, ich will dir nicht aufdrängen was du in deinem Projekt machst.
Das sind nur ein paar Gedanken eines Quereisteigers.
Es bleibt natürlich dein Baby.

gruß
bb

Hi Bernhard,

ich verstehe immer noch nicht wie du dass lösen möchtest, aber mach mal. Ich bin da auch nicht possessiv, hab schon 3 echte Babies :slight_smile:

Grüsse, Axel

Hi,

mist, jetzt ist mir der letzte Post von gestern nacht nicht mehr rausgegangen.

Nur so viel: es funktioniert so wie ichs in einem der vorigen Post beschrieben habe.

  1. Der Verbrauch in der aktuellen Stunde wird nicht mehr durch aufsummieren ermittelt, sonderen direkt aus der im Circle geloggten Pulse Summe errechnet.
    Dadurch ist mal dieser Teil des Codes sehr viel kürzer und es kann zu jedem beliebigen Zeitpunkt ausgelesen werden.

  2. Kurz nach jeder vollen Stunde wird aus dem Circle Buffer der Verbrauch der letzten Stunde abgeholt, und in IPS aufsummiert.

Zählt man nun 1) und 2) zusammen hat man den Gesamtverbrauch.
Diesen dann stündlich updaten und ab in die Datenbank
Damit hat man die exakt gleiche Genauigkeit wie im Source.

Code für 1) ist fertig.

Code für 2) funktioniert auch, hab da aber noch hardgecodete ID drinnen. Den muß ich erst noch allgemein verwendbar umbauen.
Das mit den LogVariable ist in der Tat etwas tricky, aber Jannis hat ja in dem Thread weiter vorne eine super Analyse gemacht. Damit gehts eigentlich ganz leicht.
Was auch noch reingehört ist eine passende Fehlerbehandlung. Also 2) neu lesen wenn ein Circle nicht verfügbar. Weiß aber nicht ob ich mir das noch antue.
Mit bisl schlauer Berechnung kann ich Kommunikationsstörungen oder IPS-Down zeiten von < 4Stunden tolerieren ohne das der Datenbankwert jemals falsch wird.

Sollte doch reichen, oder ?

Denke ich kanns heute fertigstellen und dir mal zur Ansicht schicken.

gruß
bb

Na das hört sich doch mal vielversprechend an! Kommst du ohne Hilfsvariablen aus?

Anyway, schick doch mal dein Code wenn du soweit bist.

Grüsse, Axel