Enertex Appliance mit SV3.1

[Sipple]

Heureka, s'läuft!

Log anbei. Vielleicht siehst du darin noch was, was nicht passt. Ich nicht

enertex.zip

[Sipple]

So sieht das aus in einem Block. Die Formatierung ist also ein wenig daneben.

Enertex_Block.png

Edit: Passt jetzt.

[wvhn]

Cool. Vielen Dank fürs geduldige Testen. Eine verbesserte Version, die auch ohne Passwort auskommt, habe ich gerade ins develop gestellt. Dazu musste ich den Umstand abfangen, dass das Interface beim Warten auf das Passwort endlos mit dem Client Protokoll-Optionen verhandelt. Von welcher Seite das ausgeht, habe ich nicht untersucht.

Am Erscheinungsbild der Appliance habe ich noch nichts verändert. Vorschläge / Mitarbeit zur Gestaltung der Darstellung der zusätzlichen Daten sind willkommen.

Diese Daten sind jetzt verfügbar:

Array
(
	[hardware_type] => 00-00-00-13-00-01 
	[add_hardw_type] => 00-00-00-25-00-01 
	[firmware_version] => 1.062 
	[uptime] => 00:01 
	[tx_to_ip_all] => 0 (ca. 0 t/m) 
	[tx_to_knx] => 0 (ca. 0 t/m) 
	[rx_from_knx] => 0 (ca. 0 t/m) 
	[overflow_to_ip] => 0 
	[overflow_to_knx] => 0 
	[tx_tunnel_re_req] => 0 
	[tp_bus_voltage] => 28.75 V 
	[tp_bus_current] => 16.2 mA 
	[tp_temperature] => 21.5 C 
	[tx_tp_rate] => 50 T/s (= 100 %) 
	[date] => 11:08:27 14.08.2021 (UTC) 
	[ip_mode] => DHCP 
	[ip] => 192.168.2.117 
	[subnet_mask] => 255.255.255.0 
	[gateway] => 192.168.2.1 
	[ntp_server] => pool.ntp.org (176.221.42.125) 
	[dns_server] => 192.168.2.1 
	[sys_multicast] => 224.0.23.12 
	[rt_multicast] => 224.0.23.12 
	[hardware_addr] => 70:b3:d5:dc:87:79 
	[knx_bus_state] => up 
	[knx_address] => 15.15.255 
	[serial_number] => 00-a6-25-80-02-ce 
	[used_stack_memory] => 7 % 
	[allocated_memory] => 81 % 
	[unused_memory] => 18 % 
	[tp_tx_buffer] => 0 % 
	[tp_tx_buffer_max] => 0 % 
	[tp_rx_buffer_max] => 0 %
	[tunnels] => Array 
	( 
		[1] => Array 
		( 
			[tunnel_1] => open (CCID 97)
			[knx_address] => 15.15.010
			[hpai_control] => 192.168.45.10:3672
			[hpai_data] => 192.168.45.10:3672
			[connect_type] => TUNNEL_CONNECTION
			[communication] => UDP CONNECTION
			[tx_tun_req] => 2422
			[tx_tun_rereq] => 0
			[rx_tun_req] => 141
			[rx_tun_rereq_identified] => 0
			[rx_tun_req_wrong_seq] => 0
			[current_tunnel_buffer] => 0%
			[connected_since_UTC] => 16:26:16 29012019
		)
		[2] => Array 
		( 
			[tunnel_2] => closed 
			[knx_address] => 15.15.011 
		)
		.
		.
		.
		[8] => Array 
		( 
			[tunnel_8] => closed 
			[knx_address] => 15.15.017 
		)
	)
	
	
)

Gruß
Wolfram

[enertegus]

Einen Reset Knopf bräuchte ich selber wahrscheinlich nicht. Eventuell einen Refresh.
Was bei den Routern noch interessant wäre kann ich nicht sagen.

ich würde bei den Geräten auch tpratemax [Telegrammratenbegrenzung] , apdu [max. Nutzlast] und tunneltime [timeout für die UDP Kommunikation] anzeigen lassen.
Bei Routern wäre sicher noch lcconfig [Routing Informationen] ganz brauchbar.

[Sipple]

Dann füge ich noch hinzu, dass bei den einzelnen aktiven Tunneln noch "Connected Since" interessant wäre.

[enertegus]

Dann füge ich noch hinzu, dass bei den einzelnen aktiven Tunneln noch "Connected Since" interessant wäre.

ja, das ist ja die Ausgabe bei tunnel xx, falls dieser als aktiv gemeldet wird.

[wvhn]

Da ich das Interface bisher noch nicht aktiv in meine alte Tebis TS Anlage (ohne ETS) eingebunden habe, hatte ich keine offene Tunnelverbindung zum Testen und habe deshalb bei den Tunnels die Doku aus der bisherigen Appliance übernommen. Habe die zusätzlichen Ausgaben jetzt oben im Thread auf Basis der aktuellen Enertex-Doku ergänzt.

ich würde bei den Geräten auch tpratemax [Telegrammratenbegrenzung] , apdu [max. Nutzlast] und tunneltime [timeout für die UDP Kommunikation] anzeigen lassen.
Bei Routern wäre sicher noch lcconfig [Routing Informationen] ganz brauchbar.

Ich hatte mich bisher auf Angaben beschränkt, die aus meiner Sicht für den laufenden Betrieb interessant sind und hatte die genannten Daten eher im Bereich der Konfigurationsdaten verortet. Ich kann aber den Service so erweitern, dass er die Daten liefert. Das Widget müssen wir dann so gestalten, dass Anwender sich die Ausgabe selber konfigurieren können.

Im Moment kämpfe ich noch mit einem anderen Problem: ab und zu erhalte ich beim Verbindungsaufbau schon beim Öffnen des Sockets keine Rückmeldung. Hier müsste PHP eine aktive Verbindung erkennen und die Ressource ID liefern, die das Skript für die weitere Kommunikation auf dem Socket benötigt. Der Enertex-Router ist dann aber in einem Zustand, in dem keine Verbindung mehr aufgebaut werden kann - auch nicht mit Putty. Es gibt wohl in diesem Zustand keinen Timeout, so dass nur noch ein Factory Reset hilft. Danach ist aber der Ereignisspeicher leer, ebenso wie das Apache Error Log, was die Suche erschwert. Sachdienliche Hinweise nehme ich gerne entgegen.

Gruß
Wolfram

[enertegus]

ab und zu erhalte ich beim Verbindungsaufbau schon beim Öffnen des Sockets keine Rückmeldung.

Ist das auch so, wenn du das mal am Wireshark beobachtest?

[Sipple]

Ich habe so ziemlich die gleichen Symptome. Also nicht ich, die Schnittstelle

Allerdings in zwei Ausprägungen, wie weiter oben schon mal kurz angerissen.
Meistens ist das Telnet Interface für max. ein paar Minuten blockiert, dann fängt sich die Schnittstelle aber und ich komme mit Putty wieder drauf.
Ein zweimal hat sie sich aber nicht mehr gefangen. Auch nach einer Stunde nicht. Aber einen Factory Reset hat es nicht gebraucht. Kurz vom Bus getrennt und es ging wieder.

[enertegus]

Möglicherweise schiebt der SVClient die Daten zu schnell zum Telnet der Schnittstelle, sodass dort eine Queue überläuft und die Daten nicht mehr komplett verarbeitet werden. Könnt ihr mal eine Pause einbauen, auf jeden Fall nicht alle 12 Telnetkommandos in eine Reihe raushauen, das könnte problematisch sein.

[wvhn]

Der Ablauf ist wie folgt:

$socket = @fsocketopen($server, $port, Fehlernummer / Text, Timeout 10 Sekunden)
if $ socket === false
   dann ist die Verbindung nicht zustande gekommen. Hier scheitert der Verbindungsaufbau bereits sporadisch.
   Absetzen Fehlermeldung und Ende.

if $socket !== false
   dann enthält $socket den "file pointer", den man zur weiteren Kommunikation braucht.
   Pause 10 ms
   Start der Verhandlung von ein paar Optionen zum Aufwärmen :-)

   ab dann jeweils 10 ms Pause vor dem Schreiben jedes Kommandos, und nochmal 10 ms Pause vor dem Lesen der Antwort

   'logout' senden
   Socket schließen
   Rückgabe aller Daten als json

Reichen 10 ms Pause aus Deiner Sicht aus?
Die eigentliche "Problemzone" @fsocketopen kann ich von außen nicht beeinflussen.

Gruß
Wolfram

[enertegus]

mach mal lieber 150 ms....

[wvhn]

Ich habe jetzt eine neue Version im develop, die mit je 150 ms Wartezeit vor dem Senden von Kommandos und vor dem Lesen der Ergebnisse stabil läuft. Entscheidend ist vermutlich aber, dass ich nach dem Senden von 'logout' nochmal eine Wartezeit eingefügt habe, bevor das php-Skript den Socket schließt. Ich denke, dass der IP-Router dadurch seinen Sendepuffer noch definiert leeren kann, bevor er die Verbindung schließt. Werde bei Gelegenheit nochmal die Wartezeiten beim Lesen und Schreiben anpassen, um die Performance etwas zu verbessern.
Die zusätzlich gewünschten Daten werden auch ausgegeben. Sie sind aber noch nicht in die Beschreibung des Arrays am Ende des Skripts eingearbeitet.

Das Skript ist als 'enertex.iprouter-v2.php' angelegt, so dass Anwender älterer Geräte die bisherige Version weiter nutzen können.

Gruß
Wolfram

[wvhn]

Passend zum Skript habe ich das Widget erweitert und als "appliance.iprouter_v2" neu angelegt. Der Code ist unten angehängt. Die Datei ersetzt die ./widgets/appliance.html nach Änderung der Dateiendung in "html".
Die Ausgabe sieht dann so aus:
appliance_v2.png

Das ist also erstmal der Ersatz für das bisherige Widget mit ein paar Zusatzinformationen in den unteren Zeilen. Mehr passt IMHO nicht in die Box, die so auch noch auf meinem alten iPhone SE ganz gut aussieht. Auf dieser Basis könnt Ihr Euch mal selbst mit weiteren Design-Ideen für zusätzliche Anzeigen austoben

Gruß
Wolfram

P.S.: wer den neuen Service schon betreibt, könnte mir zum Testen mal einen JSON-Datensatz mit echten Daten zuschicken. Dazu einfach in der Debug-Seite den letzten Abschnitt beinnend mit {"hardware_type" ... kopieren.

P.P.S: Der Service ist mir übrigens beim sehr häufigen Testen des Widgets nicht mehr abgeschmiert. Das lässt hoffen

[Sipple]

Gerne. Siehe Anhang.

Wie große wäre der Aufwand um bei einem Klick auf T1...T8 jeweils die Details des Tunnels in einem Popup zu sehen, also was beim Befehl "tunnel x" raus kommt?


Beispiel.txt