@saarlanduhu
Um zu verhindern, dass über DHCP neue IP-Adressen zugewiesen werden, kannst Du in der FB die Adresse reservieren.
Unter Heimnetz/Netzwerk/Netzverbindungen geht Du bei dem betroffenen links auf das Bleistift:
dort dann das Häkchen setzen:
Oben auf der Seite kannst Du auch einen eindeutigen Gerätenamen vergeben:
@ilovegym
Der Tipp mit dem Blockly war zielführend, danke dafür 
@gombersiob
Die Quelle finde für die Register finde ich nicht mehr. Aber hier sind die Einträge aus meiner Modbus-Instanz zum DTSU666:
Die von Sungrow ausgelieferten DTSU666 haben wohl eine Sungrow-spezifische Firmware, sodass die entsprechenden Register direkt über den Modbus verfügbar sind. Es gibt zum DTSU noch mehr Register, die z.B. die Ströme der einzelnen Phasen anzeigen.
Näheres dazu hier:
https://www.photovoltaikforum.com/thread/158136-sungrow-sammelthread-produktmanagement/?postID=2697060#post2697060
Nur um Missverständnisse zu vermeiden: Nach meinem Verständnis beschreibt der Hausverbrauch die Leistung, die im Haus "verbraucht" wird. Der Wert ist daher immer positiv. Der Hausverbrauch kann mit dem Standardaufbau des Systems nicht direkt gemessen werden (Pfad 4 in der physikalischen Darstellung). Register 13007 könnte einen entsprechend berechneten Wert haben.
Register 5600 zeigt eindeutig den vorzeichenbehafteten Leistungsfluss vom/zum Netz (Pfad 3)
Die in meinen System angezeigten Regsiterwerte lassen den Schluss zu, dass Register 5600 eher 13009 mit umgekehrten Vorzeichen entspricht.
Wenn Register 13009 negativ ist (5600 positiv), entspräche das Strompfad 10, positive Werte von 13009 (5600 negativ) dementsprechend Strompfad 9. Der jeweils andere ist dann natürlich 0.
Bleiben immer noch die Strompfade 7 und 8 zu klären, für die es ja eine Messung im WR geben müsste...
Hast Du eine verständliche Erklärung zu den Bits 4 und 7?
Für alle, die vor dem gleichen Problem stehen, hier eine Lösung zur Ermittlung des Tokens:
'use strict'
// Token für Kamera 3 ermitteln aund speichern
schedule("*/30 * * * *", async () => {
httpPost('http://192.168.22.42/api.cgi?cmd=Login', '[{ "cmd":"Login", "param":{ "User":{ "Version": 0, "userName":"YYYYYY", "password":"XXXXXXXX"}}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
let ergebnis=('' + response.data)
let position=0;
let suche = ergebnis.indexOf('"name" : "', position);
//Hier ist noch zu prüfen, on das Token IMMER genau 15 Zeichen lang ist. Ggf. muss der Filter angepasst werden!
let Token = ergebnis.slice(suche+10, suche + 25);
setState('0_userdata.0.Token_Kamera3', Token, true);
});
});
@oliverio
danke für den Tipp, habs so umgesetzt.
Hier mal für alle die ähnliches vorhaben zusätzlich der Code mit dem dann auf Grundlage des ermittelten Tokens die Steuerbefehle abgesetzt werden.
Auch in dem Code gibt es sicher Optimierungsmöglichkeiten, aber er funktioniert
'use strict'
// Token für Kamera 3 ermitteln aund speichern
schedule("*/30 * * * *", async () => {
httpPost('http://192.168.22.42/api.cgi?cmd=Login', '[{ "cmd":"Login", "param":{ "User":{ "Version": 0, "userName":"XXX", "password":"YYY"}}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
let ergebnis = JSON.parse(response.data);
let Token = ergebnis.find(el=>el.cmd=="Login").value.Token.name
setState('0_userdata.0.Token_Kamera3', Token, true);
});
});
// Kamara Links
on({id: '0_userdata.0.Kamera3_Links', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Left", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Links', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Rechts
on({id: '0_userdata.0.Kamera3_Rechts', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Right", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Rechts', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Auf
on({id: '0_userdata.0.Kamera3_Auf', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Up", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Auf', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
// Kamara Ab
on({id: '0_userdata.0.Kamera3_Ab', change: 'gt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Down", "speed":16}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
on({id: '0_userdata.0.Kamera3_Ab', change: 'lt'}, function(obj) {
let Adresse= 'http://192.168.22.42/api.cgi?cmd=PtzCtrl&token=' + getState("0_userdata.0.Token_Kamera3").val;
httpPost(Adresse, '[{ "cmd":"PtzCtrl", "param":{ "channel":0, "op":"Stop"}}]', { timeout: 3000, responseType: 'arraybuffer' }, async (err, response) => {
});
});
@homoran
@arteck
Danke Euch,
nach Verschieben der Instanz vom Slave zum Master wurde der Adapter weiterhin nur auf dem Slave angezeigt. Meine Befürchtung war, dass nach Herausnahme des Slaves die Instanz auf dem Master nicht läuft, da dort dann vermutlich einige Komponenten fehlen.
Nach einem Reboot war der Adapter dann aber auch auf dem Master zu sehen.
Sobald meine übrigen Vorbereitungen abgeschlossen sind, werde ich den Slave dann außer Betrieb nehmen.
Hallo zusammen,
ich betreibe derzeit ein Multihostsystem mit einem Master und zwei Slaves. Einen der beiden Slaves möchte ich nun gerne deaktivieren. Auf diesem Slave ist der Reolink Adapter mit zwei Instanzen installiert. Und genau das soll jetzt auf den Master umziehen.
Für die Instanzen ist das ja einfach zu erledigen indem man im Reiter "Instanzen" den Host einfach umstellt.
Der Adapter ist dann aber immer noch auf dem Slave installiert.
Wie kann man nun den Adapter umziehen? Eine weitere Installation des Adapters auf dem Master im Reiter "Adapter" ist nicht möglich 
Gruß
Peter
@martinp
gepuffert wird bei go2rtc, da der Zeitversatz bei allen Anzeigegeräten gleich ist. Verursacht wird er aber scheinbar durch den Raspi der Anzeige, da dort das Bild der Kamera 1 ständig im Home-Bildschirm angezeigt wird.
Ich gehe daher davon aus, das die Pufferung "vor" go2rtc stattfindet. Wenn man diesen Puffer ausschalten könnte, würde im Ausgabestream alle paar Sekunden mal ein Bild fehlen, was aber kein Problem darstellt.
Der Parameter Voodoo sagt mir nichts. Was bewirkt er, wo gehört er hin und gibt es dazu weitere Parameter?
@wendy2702
Ja, für den Main Stream verwende ich die volle Auflösung (2560x1920)
Bei den Reolink Kameras wird bei Reduzierung der Auflösung des Main Streams das Bild rundum auf die gewählte Auflösung geschnitten. Der zweite angebotene Stream (im Reolink Wording "Fluent") hat eine feste Auflösung von 640x480.
Bei einem Ereignis an einer der Kameras wird deren Bild im Vollbildmodus angezeigt, sodass nur der Main Stream entsprechende Qualität liefert.
Eine Reduzierung der Auflösung auf die idealerweise benötigten 1920x1080 mittels go2rtc erhöht die Latenz schneller aufgrund der hierfür erforderlichen zusätzlichen Rechenzeit.
Statt dessen habe ich mit der Frame Rate und der maximalen Bitrate experimentiert, allerdings ohne nennenswerten Erfolg
Laut htop liegen aber alle relevanten Parameter des Raspis, auf dem go2rtc läuft, im grünen Bereich.
@bahnuhr
Den Parameter #media=video nutze ich, da ich kein Audio benötige (soll Rechenzeit sparen)
Von #udp erhoffe ich mir wegen des verbindungslosen Protokolls eine schnellere Abarbeitung, da verlorene Pakete einfach wegfallen. Die dann ggf. auftretenden Bildstörungen nehme ich in Kauf.
Danke für Eure Unterstützung
Peter
@bahnuhr
@wendy2702
Bei mir laufen ioBroker und Chromium jeweils auf einem Raspberry 4 mit 8GB. Weitere Software ist auf keinem der beiden Raspis installiert. go2rtx läuft auf einem dritten Raspi 4 mit ebenfalls 8GB.
Zu Beginn, wenn eine der Kameras "Neu" aufgerufen wird, ist keine Latenz vorhanden. Im Gegenteil, über go2rtc und VIS kommen die Bilder sogar etwas schneller als direkt vom Web-Interface der Kamera:
Wenn der Stream allerdings dauerhaft angezeigt wird, steigt die Latenz innerhalb einer halben Stunde deutlich an.
Hier meine Konfigurations-Dateien von go2rtc:
[Unit]
Description=starting go2rtc server
[Service]
User=admin
WorkingDirectory=/usr/local/bin/go2rtc/
ExecStart=/usr/local/bin/go2rtc/go2rtc_linux_arm64
Restart=always
[Install]
WantedBy=multi-user.target
streams:
kamera1:
- rtsp://user:password@192.168.22.40:554/Preview_01_main#udp#media=video
kamera2:
- rtsp://user:password@192.168.22.41:554/Preview_01_main#udp#media=video
kamera3:
- rtsp://user:password@192.168.22.18:554/mpeg/media.amp
# kamera4:
# - "ffmpeg:rtsp://user:password@192.168.22.42:554/Preview_01_main#video=h264#ultrafast#width=1280"
Kamera 1 und 2: Reolink RLC 520A
Kamera 3: Doorbird
Kamera 4: Reolink 4K 8MP PTZ PoE (derzeit noch nicht produktiv)
Als weitere Software hatte ih mit gleichem Ergebnis mediamtx im EInsatz.
Motioneye habe ich aufgrund vieler negativer Berichte hinsichtlich Entwicklungsstand und auch Latenz, auch hier im Forum, nicht getestet.
Peter
@samson71
Stimmt, das Kamerabild soll nicht in VIS dargestellt werden, da dies, zumindest nach meinem derzeitigen Kenntnisstand, für einen RTSP-Stream nicht möglich ist und eine vorherige Transcodierung z.B. mittels go2rtc zu großen Latenzen führt.
Unabhängig davon steuert VIS aber die Darstellung über ein Javascript und soll soll im nächsten Schritt auch die Steuerung einer PTZ-Kamera übernehmen (in meinem Fall eine Reolink 4K 8MP PTZ PoE).
Für die Darstellung der Visualisierung muss Chromium für meinen Anwendungsfall nicht zwingend im Kiosk-Modus laufen, falls dieser mein Vorhaben beeinträchtigt. Die Aktivierung des Vollbildmodus und die Unterdrückung der Cursoranzeige sind ja auch anders möglich.
Ich gehe mal davon aus, dass noch mehr Nutzer von ioBroker bzw. VIS vor dem Problem stehen RTSP-Streams einfach "vis-gesteuert" darzustellen. Daher war mein Ansatz, das Thema hier mal zur Diskussion zu stellen.
Ggf. gibt es ja dazu auch alternative Lösungsvorschläge...
Peter
Hallo zusammen,
ich möchte den Videostream meiner Reolink Kamera (RLC 520A) in VIS einbinden.
Den bekannten Weg über go2rtc oder ähnliche Software möchte ich vermeiden, da die Latenz im Laufe der Zeit deutlich größer als 15 Sekunden wird.
Die Anzeige des Streams wird nur auf einem Monitor benötigt, auf meine Tablets oder an den PC jedoch nicht.
Dar Systemaufbau ist wie folgt:
ioBroker und Vis laufen auf einem Raspberry (RaspiSRV)
Der Monitor (Touch Screen) häng an einem weiteren Raspberry (Kiosk) auf den Chromium im Kiosk-Modus läuft.
Als mögliche Lösung bin ich auf die Idee gekommen, bei Auslösen des Triggers einfach das Kamerabild via ffplay neben die Darstellung der VIS zu legen.
Ins Unreine gesprochen:
Trigger löst aus:
nach einer bestimmten Zeit oder bei entsprechendem Tastendruck:
Ich habe das mit folgendem Javascript versucht:
on({id: '0_userdata.0.Testpunkt', change: 'gt'}, function(obj) {
var SSH = require('simple-ssh');
var ssh_Monitor1 = new SSH({
host: '192.168.22.43',
user: 'user',
pass: 'pass'
});
ssh_Monitor1
.exec('DISPLAY=:0')
.exec('export DISPLAY')
.exec('sudo ffplay -x 480 -y 360 -noborder -left 10 -top 100 rtsp://name:password@192.168.22.40:554/h264Preview_01_main')
.start();
console.log('gestartet');
});
on({id: '0_userdata.0.Testpunkt', change: 'lt'}, function(obj) { // lt: Kleiner
var SSH = require('simple-ssh');
var ssh_Monitor1 = new SSH({
host: '192.168.22.43',
user: 'user',
pass: 'pass'
});
ssh_Monitor1
.exec('sudo killall ffplay')
.start();
console.log('beendet');
});
Solange VIS auf dem Monitor nicht angezeigt wird, funktioniert das mit der Einschränkung, dass das Kamerabild verzerrt (4:3 ->16:9) im Vollbildmodus dargestellt wird und die Parameter für die Fenstergröße, Position etc. unwirksam bleiben.
Wenn VIS auf dem Monitor angezeigt wird, bleiben die Funktionsaufrufe in Skript ohne Funktion (Kein Kamerabild bzw. nichts von ffplay zu sehen).
Über einen Lösungsansatz würde ich mit freuen.
Peter
Liebe Mitstreiter,
die Ursache ist, dass bei negativen Werten die Anzeige "unten" beginnt.
Ein Wert von -6000 wird also so dargestellt:
Formal ist das richtig, benötigt wird aber der Teil von -6000 bis 0
Der Haken bei "Invertieren" bewirkt nun, dass die "Länge" des Bogens richtig dargestellt wird:
Da in meiner Grafik keine Werte angezeigt werden sollen, würde alles nach Spiegelung und Drehung, wie oben gezeigt, passen. Dummerweise wird nach Aktualisierung der Messwerte beim Aufbau der Grafik die Invertierung nicht mehr berücksichtigt.
Um das Problem zu umgehen, werde ich also die negativen Werte in einem eigenen Objekt in positive Werte umwandeln und diese dann verwenden...
Hallo zusammen,
ich möchte die Lade- und Entladevorgänge meiner PV-Batterie mit einer runden Anzeige visualisieren.
Entladevorgänge sollen nach rechts angezeigt werden, Ladevorgänge nach links.
Etwa so:
Entladen
Laden
Dazu habe ich zwei Widgets übereinander gelegt und mittels CSS entsprechend gedreht und gespiegelt.
[{"tpl":"tplJustgageJustGage","data":{"g_fixed":true,"g_visibility":false,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":true,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":1,"visibility-groups-action":"hide","is_tdp":false,"factor":"1","balance1":"1","balance2":"1","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"oid":"0_userdata.0.Testzahl","min_oid":"0","mid_oid":"4000","max_oid":"8000","hideMinMax":true,"donut":false,"pointer":false,"invert_value":false,"hideInnerShadow":true,"noGradient":false,"fullBri":false,"labelOffsetY":"1","color1":"#ffff00","color2":"#ff7000","color3":"#ff0000","gaugeColor":"rgba(100,100,100,2)","donutStartAngle":"90","titleOffsetY":"-1","sector1":"","sector2":"","gaugeWidthScale":"20","digits":"0","shadowVerticalOffset":"7","hideValue":true,"name":"Entladen","class":"DreheImg","valueOffsetY":"-3","shadowSize":"-2"},"style":{"left":"433px","top":"25px","z-index":"20","width":"700px","height":"700px"},"widgetSet":"justgage"},{"tpl":"tplJustgageJustGage","data":{"g_fixed":true,"g_visibility":false,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":true,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":1,"visibility-groups-action":"hide","is_tdp":false,"factor":"","balance1":"","balance2":"","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"oid":"0_userdata.0.Testzahl","min_oid":"-8000","mid_oid":"-4000","max_oid":"0","hideMinMax":true,"donut":false,"pointer":false,"invert_value":true,"hideInnerShadow":true,"noGradient":false,"fullBri":false,"labelOffsetY":"","donutStartAngle":"90","color1":"#ffff00","color2":"#a0d000","color3":"#00ff00","gaugeColor":"rgba(100,100,100,2)","class":"SpiegeleUndDreheImg","hideValue":true,"digits":"","gaugeWidthScale":"20","name":"Laden","valueOffsetY":"","shadowSize":"-4","sector1":"","sector2":"","shadowVerticalOffset":"-1","titleOffsetY":"-6"},"style":{"left":"122px","top":"25px","z-index":"20","width":"700px","height":"700px"},"widgetSet":"justgage"}]
Hier noch die CSS:
.SpiegeleUndDreheImg{
transform: scaleX(-1) rotate(90deg);
}
.DreheImg{
transform: rotate(90deg);
}
Mein Problem ist nun folgendes:
Wenn die Batterie vom Lade- in den Entladezustand übergeht, sollte die Anzeige aus dem linken, grünen Bereich in den roten, rechten Bereich wechseln.
Das tut sie aber nur teilweise.
Das "rechte" Widget tut was es soll, das Linke dagegen zeigt einen "vollen Ausschlag"
Wenn am dann den Browser neu lädt (F5) kommt die richtige Anzeige:
Wozu das alles?
Auf dem Visualisierungsmonitor möchte ich zusätzlich zur PV-Grafik eine schnelle, aus der Ferne erkennbare Übersicht über die Aktivität der Batterieanlage haben.
So sollte das beim Laden aussehen:
Nach der Aktualisierung der Batterieleistung (in der Grafik die 579W) wird die Anzeige dann aber falsch:
Die Ursache liegt scheinbar hier:
Wenn ich diesen Haken nicht setze, zeigt er die Differenz zwischen dem tatsächlichen Messwert und dem Minimalwert an. Im Beispiel oben: -8000-(-243) = 7757
Beim Entladen wird der Wert dann noch größer
Beispiel: Ein Entladevorgang mit 5000W wird dann mit -8000 - 5000 = -13000 visualisiert (aber wegen des Überlaufs in der Grafik nur als -8000 angezeigt)
Habt Ihr eine Erklärung dafür bzw. einen Lösungsansatz?
@homoran Mit dem Dezimalpunkt habe ich es auch in verschiedenen Varianten getestet. Macht keinen Unterschied. Auch die Meldung ist gleich:
Der Datenpunkt zeichnet Temperaturen mit einer Dezimalstelle auf:
