Diskussionsthread EDOMI-Releases/Updates

[drasche]

Hallo Gemeinde,

hatte vor etlichen Monaten mal eine Edomi-Version installiert und erste Geh-Versuche damit gemacht. Hat mich echt überzeugt und gaert: Hut ab! Was du da auf die Beine gestellt hast ist der Hammer. Zwischenzeitlich ist das Haus fertig und ich kann hier endlich weitermachen.

Wollte hier nur kurz was mitteilen, vielleicht hat der ein oder andere das Problem auch schon mal gehabt. Hab vor ein paar Tagen meine alten 1.30er Edomi Version auf die aktuelle 1.58 hoch gepatcht. Hab danach aber keinen Zugriff mehr auf den KNX Bus gehabt. So gar nicht mehr :-( Hab den IP-Router von MDT und bin mit dem auch bis jetzt hoch zufrieden. Aber der Router und Edomi wollten nicht zusammen.

Diese Fehlermeldung hab ich hunderfach gesehen:

2018-07-25 15:53:35	089370	29323	OK	EDOMI @ CE | DESCRIPTION_REQUEST an 192.168.1.29:3671 / Raw: 06100203000e0801c0a800ebc350
2018-07-25 15:53:46	006576	29323	ERROR	EDOMI @ CE | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhalten
2018-07-25 15:53:46	018970	29323	OK	EDOMI @ CE | DISCONNECT_REQUEST / Raw: 06100209001000000801c0a800ebc350
2018-07-25 15:53:46	021158	29323	ERROR	KNX-Verbindung verloren.

Hab den Router 4 mal neu geflasht, mit dem MDT Support gesprochen, meine PAs zig mal neu gesetzt bzw. angepasst. Immer der gleiche Fehler. Hab Edomi in einer VM unter HyperV laufen und hab dann noch angefangen, die Netzwerkinterfaces zu testen, hab mein LAN auf den Kopf gestellt und meine VLANs angepasst. Nix hat geholfen. Dann bin ich durch Zufall auf diesen LogEintrag gestossen (hatte vorher immer nur im KNX-Log nachgesehen...):

2018-07-28 23:03:32	828466	KNX	27677	KNX-Verbindung: Control-Endpoint: 192.168.0.235:50000	Ok
2018-07-28 23:03:32	828603	KNX	27677	KNX-Verbindung: Data-Endpoint: 192.168.0.235:50001	Ok

Der Eintrag hatte mich dann schon gewundert, denn meine Edomi-Adresse ist die 192.168.1.27. Nach ein wenig Recherche hab ich dann gefunden, dass es seit der Version 1.50 in der "config.php" zwei neue Parameter gibt, die vorbelegt sind mit der 192.168.0.235, nämlich "global_visuIP" und "global_knxIP". Nach einigem experimentieren hab ich dann festgestellt, dass wenn ich die beide auf die Edomi-Adresse (in meinem Fall die 192.168.1.27) setze, alles funktioniert.

Das nur als Hinweis, falls jemand das gleich oder ein ähnliches Problem hat :-)

Ansonsten kann ich nur sagen: Super Job gaert, bitte mach weiter so!!!

Grüsse
Dirk

[Winni]

Kameraarchive:

• Basiskonfiguration: global_camArchivThumbWidth und global_camArchivThumbQuality wurden entfernt (es werden keine Thumbsnails mehr erzeugt)
• KO "letzte Archivierung" (Metadaten): der letzte Parameter (Thumbsnail-Dateiname) entfällt

dem weine ich schon ein wenig nach... war das zwingend nötig? Damit konnte man schön den letzten Event neben der Livecam einblenden.

[mfd]

Was die neue DVR-Funktion und den Hinweis auf eine zusätzliche Festplatte für die Archivierung anbelangt habe ich mich vor einiger Zeit schon gefragt, ob es nicht sinnvoll wäre eine Art Schutzmechanismus zu haben, der verhindert dass das Systemlaufwerk volllaufen kann?

Ich habe selber beim Spielen mit einer Überwachungskamera nach ein paar Tagen plötzlich 100% HDD-Belegung in der EDOMI-Übersicht entdeckt. Eine standardmäßige Begrenzung (XY % von HDD oder Größe in GB) über die Basiskonfiguration wäre IMHO eine sinnvolle Einstellung um böse Überraschungen zu vermeiden.

[blaky]

Kameraeinstellungen:

• MJPEG: Funktion zum Grabben eines Einzelbildes optimiert

leider klappt der mjpeg DirektStream der Hikvision immer noch nicht... die Vorschau klappt aber

ansonsten alles top auf den ersten Blick

[gaert]

Auf den direkten Stream hat EDOMI keinen Einfluss... Der wird einfach im Browser abgerufen - als Source eines IMG-Tags.

[gaert]

mfd EDOMI gibt doch eine Warnung aus (System-KO), wenn die Restkapazität eng wird - darauf könnten Deine Archivierungslogiken doch einfach reagieren...

[mfd]

Ja, das sicher, aber es muss ja vom Anwender erst eine entsprechende Ausgabe auf den Bus/Visu oder per Mail angelegt werden.
Ich bin damals nur zufällig auf die überfüllte Platte aufmerksam geworden, als ich in den Logfiles einen Fehler hatte, der sich auf ein zu lange laufendes bzw. abgebrochenes Backup bezogen hat. Bis zu diesem Zeitpunkt war mir gar nicht richtig klar, dass alle Kameraarchive auch mit ins Backup einbezogen werden...

Ich fände es clever, wenn das System sich in dieser Hinsicht selber schützen könnte und es den Plattenplatz nicht beliebig weit aufbrauchen kann. Wenn per Konfig voreingestellt bspw. nur 10% Plattenplatz durch Kameraarchive verbraucht werden kann, dann kann in dieser Hinsicht schon nichts passieren. Alle die, die mehr wollen können händisch jederzeit einen anderen Wert eintragen, müssen dann aber wissen was sie tun. So ähnlich ist es bei anderen Voreinstellungen ja auch.

So in der Art kenne ich das zumindest von einfachen NAS-Systemen mit NVR-Funktion. Dort wird gleich beim Setup bzw. in der Grundeinstellung begrenzt wieviel die Kameras überhaupt belegen dürfen.

[blaky]

Auf den direkten Stream hat EDOMI keinen Einfluss... Der wird einfach im Browser abgerufen - als Source eines IMG-Tags.

hallo gaert,
könnte das eventuell der Grund sein?

habe das im Cometvisu Forum gefunden:

Normalerweise legt man in der CV folgenden Link an:

Code:

<image src="http://user:pass@IP/Streaming/Channels/2/preview"/>

Das funktioniert zwar auf einigen Geräten/Browser aber nicht unter Android mit Chrombrowser.

Diese Art der Authentifizierung wurde aus Sicherheitsgründen deaktiviert, wenn es sich um einen eingebunden Link handelt.

Edomi macht doch einen eingebunden Link.

denn ein direkt Aufruf der URL funktioniert.. nur wenn er eingebunden ist nicht.!?

Wie könnte man das lösen ohne es durch VLC oder ähnliches zu schleifen?

[jonofe]

leider klappt der mjpeg DirektStream der Hikvision immer noch nicht... die Vorschau klappt aber

Das liegt doch bestimmt daran, das dieser nur per RTSP bereitgestellt wird, nicht aber per HTTP.
Mein Verständnis war, dass Edomi nur HTTP unterstützt.

[blaky]

Das liegt doch bestimmt daran, das dieser nur per RTSP bereitgestellt wird, nicht aber per HTTP.
Mein Verständnis war, dass Edomi nur HTTP unterstützt.

nein die Cam hat einen RTSP h.264 Stream und eine http mjpeg Stream. das Edomi nativ kein RTSP kann ist klar.
wenn ich direkt

[URL]http://user:pass@IP/Streaming/Channels/102/httppreview[/URL]

in Chrome oder VLC oder Firefox aufrufe bekomme ich einen mjpeg Stream in Edomi unter dem Vorschaubild sehe ich auch ein Bild aber in der Visu als Mjpeg Direktstream kommt nichts.

lt. Gaert ist der einzige Unterschied zwischen einem direkt URL aufruf die Einbettung der URL als src im Img Tag
hab jetzt mal in Chrome mit getraced:

 [Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are blocked.

Würde das daher nicht als Edomi Problem sehen, sondern als Browser Problem daher die Frage kann man das umgehen ?

[jonofe]

in Chrome oder VLC oder Firefox aufrufe bekomme ich einen mjpeg Stream in Edomi unter dem Vorschaubild sehe ich auch ein Bild aber in der Visu als Mjpeg Direktstream kommt nichts.

Interessant. Bei meiner Hikvision funktioniert dieser Link in Firefox, nicht aber in Chrome oder VLC. Das scheint also auch noch OS abhängig zu sein.

[ggt]

gaert Hallo Christian,

danke für die neue Version die ich mir gerade in einer virtuellen Testumgebung ansehe.

In der 1.58 konnte man die Kameraeinstellungen maskieren und diese dann für ein Archiv nutzen. Das nutze ich aktuell für den Versand eines Bildes per mail. (Klingel - Kameraarchiv - Kamerabild hinzufügen – CamMailer)

In der 1.59 entfällt die Maskierung zu Gunsten der Ansichten, ok.

Für ein Kameraarchiv kann ich aber nur eine Kameraeinstellung also nicht maskiert auswählen und nicht eine neue Kameraansicht die man ja in den Einstellungen (Ausschnitt) sehr gut anpassen kann. Laut Hilfe „die Kameraansicht für ein Archiv ist frei wählbar“.

Was habe ich übersehen, damit ich das wie in der 1.58 umsetzen kann?

[gaert]

Damit ist die Visu und die "Kameraaufnahmen" (Adminseite) gemeint - dort ist die Ansicht frei wählbar. Die Ansichten werden auf dem Client erzeugt (in Javascript) und sind auf dem Server nicht verfügbar - und somit auch nicht für "CamMailer" & Co...

[ggt]

Schade, das bedeutet mit der 1.59 kann mann keine Bildanpassung für ein Archiv erzeugen.

Besteht die Möglichkeit, das es auch bei deinem neuen Konzept vielleicht wieder möglich sein könnte/wird?

[Winni]

Hat jemand die Entzerrfunktion seiner Kamera schonmal von extern über ReverseProxy (ohne VPN) versucht? Bei mir wird das Bild nicht aufgebaut. Mit VPN kein Problem. (Google Chrome sowohl unter Windows, als auch Android)

Auch auf den Admin Seiten ist das rechte (berechnete) Fenster beim Anlegen einer Kameraansicht grau.