gehört das Thema nicht eher in den Admin-Thread?

Ich hatte vor 4 Jahren mal für FHEM ein Script geschrieben, um die von meiner Wetterstation (WH3080) gelieferte Windrichtung für die grafische Darstellung aufzubereiten. Das Problem ist ja, dass speziell bei schwachem Wind oder Windstille die Windfahne irgendwo hin zeigt (z.B. durch eine Thermikablösung oder Verwirbelung an umgebenden Hindernissen). Damals hatte ich folgende Grafik zur Verdeutlichung verwendet:

Man sieht bei der Windrichtung, dass die Originaldaten eher unbrauchbar sind.

Hier ein Beispiel, wie es jetzt bei mir ausschaut:

Die Grafiken werden bei mir ausserhalb von ioBroker aus den mit dem SQL-Adapter in MariaDB gespeicherten Daten erstellt.
Wenn der Wind zu schwach ist, wird die Windrichtung überhaupt unterdrückt.

Allerdings ist die Mittelwertbildung bei der Windrichtung etwas komplizierter, da man es hier mit Polarkoordinaten hat. D.h. man kann nicht einfach den Winkelwert mitteln. Z.b. wäre der arithmetische Mittelwert zw. NO (45°) und NW (315°) dann 180°, also S, tatsächlich ist er aber 0° (N). Daher muss man den Winkel in West-Ost Komponente und Nord-Süd Komponente zerlegen und getrennt den Mittelwert berechnen.
Die Grundidee für die Berechnung hab ich dabei PYWWS abgeschaut.

Jetzt hab ich mich endlich dazu aufgerafft, das Script in Javascript zu erstellen um es direkt in IoBroker verwenden zu können:

const logit = false;	// hier kann bei Bedarf die Logausgabe aktiviert werden

/*
	minage:
	Erst nach Ablauf dieser Zeit wird ein neuer Wert berücksichtigt.
	Ist quasi eine Art Entprellung.
*/
const minage = 0;

/*
	avtime:
	Maxmimaler Zeitraum, der gemittelt werden soll
*/
const avtime = 900;

/*
	decay:
	1 -> alle Werte werden gleich gewichtet
	0 -> nur der aktuelle Wert wird verwendet.
	in der Praxis wird man Werte so um 0.75 nehmen
*/
const decay = 0.75;

/*
	minspeed:
	da bei sehr geringer Windgeschwindigkeit die Windrichtung üblicherweise nicht
    eindeutig ist, kann mit minspeed ein Schwellwert angegeben werden
    Ist die (gewichtetete) mittlere Geschwindigkeit < minspeed wird undef zurück geliefert
*/
const minspeed = 0.5;


/*
	Maximalgröße des Arrays
	Der Wert hängt davon ab, in welchem Intervall die Wetterstation die Daten liefert.
	Richtwert: avtime / Intervall + 1;
*/
const maxentries = 40;

/*
	ID's der Quellobjekte für Windgeschwindigkeit und Richtung
*/
const wsid = "alias.0.Wetterstation.windspeed";			// Windgeschwindigkeit in m/s
const wdid = "alias.0.Wetterstation.winddir";				// Windrichtung (0 - 15)

/*
	Die folgenden 3 Objekte müssen manuell angelegt werden!
	hier wird dann jeweis die ID eingetragen:
*/
const historyid = "0_userdata.0.WindDirAverage.history";			// Speicher der History vom Typ Array
const wdavgid = "0_userdata.0.WindDirAverage.WindDirAvgDegree";	// Mittelwert der Windrichtung in Grad vom Typ Number
const wdavgtid = "0_userdata.0.WindDirAverage.WindDirAvgText";		// Mittelwert der Windrichtung als Text vom Typ String

var i = 0;
var age = 0;
var ltime = 0;
let oldhistory = getState(historyid).val;				// gespeicherten Buffer holen
var history = new Array();								// Datenbuffer initialisieren

if (decay > 1){		// darf nicht >1 sein
	decay= 1;
}
if (decay < 0){		// darf nicht <0 sein
	decay= 0;
}


if (oldhistory.length > 0) {							// wenn im gespeicherten Buffer Daten vorhaden sind
	history = oldhistory;								// diese in den Datenbuffer übernehmen
	ltime = history[history.length - 1].time;			// Zeitstempel des letzten Eintrages 
}

var num = history.length;

on({id: wsid, change: 'any'}, function(wsobj) {
	let ws = wsobj.state.val;							// WindSpeed(m/s)
	let ctime = (wsobj.state.ts / 1000).toFixed(0);		// Timestamp (s)
	let wd = getState(wdid).val * 22.5;					// WindDirection (Grad)
	let stime = history[0].time;						// Zeitpunkt des ältesten Wertes
	age = ctime - ltime;								// Zeitspanne seit dem vorhergehenden Wert

	if (age > minage) {									// erst nach Ablauf von minage einen neuen Wert verarbeiten (Entprellung)
		if (history.length >= maxentries) {				// falls der Datenbuffer voll ist,
			history.shift();							// den ältesten Eintrag entfernen
		}
		let wdr = (degToRad(wd)).toFixed(3);
		let newentry = {
            windspeed: ws,
            winddir: wdr,
            time: ctime
        };
		history.push(newentry);							// neue Daten dem Datenbuffer hinzufügen
		num = history.length;
		if (logit) {
			log(sprintf("num: %u ts: %u age: %u ws: %0.1f, wd: %u, wdr: %u", num, newentry.time, age, newentry.windspeed, wd, newentry.winddir));
		}
		ltime = ctime;
		var anz = 0;
		var sanz = 0;
		var sumsin = 0.0;
		var sumcos = 0.0;
		var sumspeed = 0.0;
		var wdavg = 0;
		var weight = 0;
		age = 0;
		maxage = 0;
		for (let i = 0; i < num; i++) {					// nun die Daten im Buffer verarbeiten
			ws = history[i].windspeed;
			wdr = history[i].winddir;
			ts = history[i].time;
			age = ctime - ts;
			if (age > avtime) {							// zu alte Einträge entfernen
				history.shift();
				i--;
				num--;
			} else {									// Werte aufsummieren, Windrichtung gewichtet über Geschwindigkeit, decay und age
				weight = ws * decay ** (age / avtime);
				if (age < (avtime / 4)) {				// für die Mittelwertsbildung der Geschwindigkeit wird nur ein 4tel von avtime genommen
					sumspeed += weight;
					sanz++;
				}
				sumsin += ((Math.sin(wdr)).toFixed(3) * weight);
				sumcos += ((Math.cos(wdr)).toFixed(3) * weight);
				anz++;
			}
		}
		setState(historyid, {							// Datenbuffer im Datenpunkt speichern
			val: history,
			ack: true
		});
		let avg = radToDeg(Math.atan2(sumsin, sumcos));
		wdavg = ((avg + 360) % 360).toFixed(0);			// Mittlere Windrichtung in Grad
		wdt = wd_to_text(wdavg);						// und als Text
		let wdstr = '-';
														// neuen Wert nur ausgeben, wenn die durchschnittliche Geschwindigkeit groß genug ist
														// und überhaupt ein Wert berechnet wurde
		if ((anz > 0) && (sanz > 0) && ((sumspeed / sanz) >= minspeed)) {
			setState(wdavgid, {
				val: Number(wdavg),
				ack: true
			});
			wdstr = wdt;
		}
		setState(wdavgtid, {
			val: wdstr,
			ack: true
		});
		if (logit) {
			log(sprintf("sanz: %u ws: %0.1f avgws: %0.1f anz: %u avg: %0.1f wdavg: %u wdt: '%s'", sanz, ws, sumspeed / sanz, anz, avg, wdavg, wdstr));
		}
	}
});

function degToRad(degrees) {
  return degrees * (Math.PI / 180);
};

function radToDeg(rad) {
  return rad / (Math.PI / 180);
};

function wd_to_text(wd) {
	let wdt = ['N', 'NNO', 'NO', 'ONO', 'O', 'OSO', 'SO', 'SSO', 'S', 'SSW', 'SW', 'WSW', 'W', 'WNW', 'NW', 'NNW', 'N'];
	let w = (wd / 22.5).toFixed(0);
	return wdt[w];
}

Ich hab versucht, möglichst viel in den Kommentaren zu erklären! Anpassen muss man auf jedenfall die beiden Variablen wsid und wdid (Zeilen 41 und 42), das sind die Objekte, die für die Berechnung herangezogen werden. Bei mir ist wdid ein Objekt, in das von der Wetterstation nur eine Zahl (0-15) geschrieben wird. In der Zeile 76 wird daraus dann die Windrichtung in ° berechnet. Je nach eigener Wetterstation ist hier also eventuell auch eine Anpassung nötig!

Die Ausgabe erfolgt dann in die in den Zeilen 48-50 definierten Objekte. Die Objekte müssen zuvor manuell angelegt werden! Ich hab aber mal meinen Objektbaum in eine JSON-Datei exportiert, die man in der Objektansicht oben mit dem Aufwärtspfeil importieren kann:
0_userdata.0.WindDirAverage.json

Ich muss noch erwähnen, dass ich keine professionelle Javascript Programmiererin bin, es kann also durchaus sein, dass man das eine oder andere noch eleganter lösen könnte. Aber das Script tut, was ich damit erreichen will.

Sabine

@dslraser ich hab mir jetzt mal für einen Thermostat einen eigenen Alias angelegt mit "Getrennte Alias IDs für lesen und schreiben". Lesen vom SET_POINT_MODE und schreiben in CONTROL_MODE.
Im iQontrol dann diesen Alias für CONTROL_MODE ausgewählt, noch die Werteliste beim Alias-Object eingetragen und schon wird im iQontrol Manu angezeigt, wenn man das im RaspberryMatic umstellt (und umgekehrt).

@kilolima ich denke, Sebastian hat so schon genug mit den diversen Wünschen zu kämpfen, jetzt noch eine Zugriffskontrolle mit einzubauen würde es nicht einfacher machen. Ausserdem bitte daran denken, Sebastian (@s-bormann ) macht das in seiner Freizeit!

@fabian1 sagte in js-controller 3.3 jetzt im STABLE!:

@jan1 said in js-controller 3.3 jetzt im STABLE!:

@fabian1
Wo legt er dann die DPs der eigenen Geräte an? Ich dachte das macht der Adapter eh automatisch richtig.

Ich versteh Dein Problem, wenn das nicht dort gemacht wird, wird dann aber etwas OT hier

Wenn ich in meiner ESP8266 Firmware Daten per MQTT sende dann erstellt er die Datenpunkte in MQTT.0.GerätXYZ das stimmt! ABER MQTT geht ja in beide Richtungen, ich muss ja die Möglichkeit haben selbst Topics anlegen zu können.

Ich hab als MQTT-Broker bei mir Mosquito im Einsatz, weil ich finde, sowas sollte unabhängig vom ioBroker laufen.
Als Adapter verwende ich dann den MQTT-Client Adapter. Bei dem kann man bei jedem Objekt einen Topic einstellen, ob man damit den Wert publishen will bzw. ob dieser Topic für das Objekt abonniert werden soll:

@marc-berg sagte in Node-RED Nodes für externe ioBroker Integration:

Super! Ab besten jetzt noch fleißig testen, in zwei Wochen befinde ich mich eine Weile in einer praktisch internetfreien Zone.

Bis jetzt laufen alle Flows, so wie sie sollen. Hab inzwischen die Node-Red Instanz von IOB gestoppt...

@vepman Falls nicht eh schon geschehen, in der Adapter Ansicht den Experten Modus aktivieren (über das Symbol oben rechts) und dann beim Adapter in der Spalte "Installieren" auf den "Pfeil nach oben" (Upload) clicken.

@feuersturm naja, das ist dann alles andere als Benutzerfreundlich. Vorallem, weil ja nicht klar ist, welche Einheit die Zahl dann hat (Pixel? Inch? cm? %?).
Der Default ist aber jedenfalls so unbrauchbar, wenn man sich statt Namen dann irgendwelche Object-ID's (14 Hexziffern) merken muss

@marc-berg nach einigem herumprobieren tuts jetzt auch mit der aktuellen Version!

Die Änderung im Verhalten war zwischen 1.0.2 und 1.1.0. Irgendwie reagiert da ab 1.1.0 der MQTT-Teil der objects offenbar anders, ich hatte ja in meinem Flow nichts geändert. Das Konstrukt mit dem Subflow hab ich übrigens aus dem Forum (glaub von @mickym, bin mir aber nicht sicher).

Wobei das eigentliche Problem die eigenwillige Ansteuerung der Shellies über MQTT ist. Die verwenden bei Schalten z.B. "on" und "off", iQontrol verwendet aber true/false.
Bisher hatte ich da beim jeweiligen output object dann den Wert über MQTT gepublisht, weil der true oder false ist wärend command eben den String erwartet, wobei ich aber "changes only" aktiviert hatte.

Wenn ich jetzt die object Liste im ioBroker abschaue, ändert sich aber der Zeitwert für "Letzte Änderung" auch bei Objekten, die nicht geändert werden. Im changelog für 1.1.0 schreibst du da "lc (last changed) always uses current time". Meiner Meinung nach sollte lc aber nur geändert werden, wenn sich der Wert des objects auch geändert hat!

Jetzt hab ich aber den iQontrol-Teil vom output object erweitert (Target-Value-List) und wandle da true/false in "on"/"off" um und schicke den Wert an das command object.

Jedenfalls ist die CPU-Auslastung jetzt auf mit 1.1.1 im normalen Bereich!

Danke für deine Mithilfe und deine Intergration!

Eigentlich müsster der Thread-Titel inzwischen angepasst werden (1.3.x ist ja nicht mehr aktuell)

@homoran mit "eigenen Broker" meinte ich den vom Shelly Adapter!

@samson71 @da_Woody so mach ich es ja auch (mit node-red).
Ich frag mich halt nur, welchen Vorteil der eigene Broker bringen soll.

Warum verwendet der Shelly Adapter eigentlich überhaupt einen eigenen MQTT-Broker und isoliert die Geräte damit von der übrigen MQTT-Welt?

@41vsy sagte in shelly adapter und node.js update:

@homoran

@thomas-braun

ok.

Ich habe in einem Forum ein ähnliches Problem gefunden. Und da hat man auf einen Befehl.

ifconfig
route
cat /etc/resolv.conf

Ergebnis bei mir:

iob@iobroker:~$ ifconfig
route
cat /etc/resolv.conf
-bash: ifconfig: command not found
-bash: route: command not found
# --- BEGIN PVE ---
search local
nameserver 192.168.178.1
# --- END PVE ---

Also ich weiß, dass mein Netzwerk 192.168.40.xxx ist. Gibt es da einen Zusammenhang? -- schon mal riesen Dank

Wenn dein Rechner im Subnetz 192.168.40.0/24 ist und in /etc/resolv.conf aber 192.168.178.1 eingetragen ist wird das eher nicht funktionieren! Welche IP hat denn dein Router? Ich vermute mal, dass der 192.168.40.1 als IP hat, die solltest du dann in der /etc/resolv.conf eintragen (ausser du hast auch pihole in Verwendung).
Unter debian (wird normal in lcx unter ProxMox verwendet) kann man die eigene IP mit "ip a" abfragen.

@thomas-braun man kann auch mit dos2unix die Windows-Zeilenenden entfernen.

@marc-berg danke für die schnelle Korrektur! Hab eben das update eingespielt.

@shadowhunter23 ok, hatte ich übersehen! Danke für den Hinweis!

Falls wer ein Template für Debian 13 braucht, ich hab das hier gefunden: Debian 13 (Trixie) LXC Image for Proxmox 9
Damit lässt sich ein neuer LXC erstellen.

@marc-berg nach einigem herumprobieren tuts jetzt auch mit der aktuellen Version!

Die Änderung im Verhalten war zwischen 1.0.2 und 1.1.0. Irgendwie reagiert da ab 1.1.0 der MQTT-Teil der objects offenbar anders, ich hatte ja in meinem Flow nichts geändert. Das Konstrukt mit dem Subflow hab ich übrigens aus dem Forum (glaub von @mickym, bin mir aber nicht sicher).

Wobei das eigentliche Problem die eigenwillige Ansteuerung der Shellies über MQTT ist. Die verwenden bei Schalten z.B. "on" und "off", iQontrol verwendet aber true/false.
Bisher hatte ich da beim jeweiligen output object dann den Wert über MQTT gepublisht, weil der true oder false ist wärend command eben den String erwartet, wobei ich aber "changes only" aktiviert hatte.

Wenn ich jetzt die object Liste im ioBroker abschaue, ändert sich aber der Zeitwert für "Letzte Änderung" auch bei Objekten, die nicht geändert werden. Im changelog für 1.1.0 schreibst du da "lc (last changed) always uses current time". Meiner Meinung nach sollte lc aber nur geändert werden, wenn sich der Wert des objects auch geändert hat!

Jetzt hab ich aber den iQontrol-Teil vom output object erweitert (Target-Value-List) und wandle da true/false in "on"/"off" um und schicke den Wert an das command object.

Jedenfalls ist die CPU-Auslastung jetzt auf mit 1.1.1 im normalen Bereich!

Danke für deine Mithilfe und deine Intergration!

@marc-berg ich hab jetzt mal mit beiden Versionen Logfiles mittels flogger (die rosa nodes im Bild unten) mit geschrieben. Dabei verhält sich seltsamerweise die mqtt-in node "shellies/+/status/#" anders, wenn ich deine aktuelle node-red-contrib-iobroker Version installiere. Es geht hier um den mit der Ellipse eingekreisten Teil des Flows:

Hier die Logfiles mit der alten Version:
mqtt-in: input-old.log
iob-out: iob-out-old.log

Und hier mit deiner aktuellen Version:
mqtt-in: input-new.log
iob-out: iob-out-new.log

Ich verstehe da einfach nicht, warum mit dem Update von node-red-contrib-iobroke auf 1.1.1 sich dann die mqtt-in node anders verhält. Die sollte sich ja durch das Update nicht ändern.