Implementierungswunsch MQTT / FHEMWEB

Begonnen von flummy1978, 23 Januar 2025, 23:41:41

Vorheriges Thema - Nächstes Thema

flummy1978

Hallöchen,

ich weiss nicht ob das eine Frage für FHEMWEB oder MQTT ist aber in MQTT2_DEVICE kommt es mir vor als wäre es hier am meisten zu gebrauchen.

Ich wollte in meinen MQTT (Wifi) Devices gern einen Link zur Oberfläche haben, aber eben nicht im STATE wie es bei vielen Templates bereits der Fall ist, sondern im Reading weit oben angeordnet ist (ahref zb - ist dann alphabetisch auch oben). Noch lieber wäre mir Internals - weil das weit oben ist ohne durch eine lange Liste scrollen zu müssen) aber ich denke darauf lässt sich niemand ein ;) Aktuell helfe ich mir mit einem userReading, das dann leider sehr weit unten landet.

Bsp für ein Tasmota Gerät:
link {return("<html><a href='http://".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))."/' target='_blank'>".ReadingsVal($name,"IPAddress",ReadingsVal($name,"Info2_IPAddress","none"))."</a></html>")}
Bsp für ein Shelly
link {return("<html><a href='http://".ReadingsVal($name,"ip","none")."/' target='_blank'>".ReadingsVal($name,"ip","none")."</a></html>")}
Wäre es möglich sowas in das Modul bzw FHEMWEB aufzunehmen?

Vielen Dank schon im Vorfeld fürs lesen :)
VG
Andreas

passibe

#1
Ich löse das z.B. bei Tasmota-Geräten über den devStateIcon, der ja auch html-Code enthalten kann. Damit habe ich dann auch direkt eine Anzeige, ob das Gerät online ist oder nicht:

{my $onl = ReadingsVal($name,"LWT","Offline") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";
my $socket = ReadingsVal($name,"state","undefined") eq "on"?"taster_ch_an_gruen":"taster_ch_aus_rot";
"<div><a href=\"http://".ReadingsVal($name,"Info2_IPAddress","none")."/\" target=\"_blank\">".FW_makeImage($onl).' <a href="/fhem?cmd.dummy=set '.$name.' toggle&XHR=1">'.FW_makeImage($socket)."</a></div>"}
(sorry, ist vielleicht nicht der allerschönste Code, vor allem hinsichtlich der nicht immer einheitlichen Anführungszeichen (" vs. '), aber tut was er soll)

flummy1978

Zitat von: passibe am 24 Januar 2025, 00:23:49Ich löse das z.B. bei Tasmota-Geräten über den devStateIcon, der ja auch html-Code enthalten kann. Damit habe ich dann auch direkt eine Anzeige, ob das Gerät online ist oder nicht:
Das ist exakt das was ich oben meinte:
ZitatIch wollte in meinen MQTT (Wifi) Devices gern einen Link zur Oberfläche haben, aber eben nicht im STATE wie es bei vielen Templates bereits der Fall ist
Und STATE ist eben auch das devStateIcon. Der Hintergrund ist einfach: Das Icon ist IMMER da (also auch in der mobilen Darstellung, auf anderen Auflösungen, Tablets oder auch im Floorplan. Die IP Adresse der jeweiligen Geräte brauche ich nur beim Basteln / Programmieren etc, also am PC. Hier ist es kein Problem auf das Device -> Reading zu klicken um auf die Seite zu kommen.

VG
Andreas

TomLee

Zitat von: flummy1978 am 23 Januar 2025, 23:41:41Noch lieber wäre mir Internals - weil das weit oben ist ohne durch eine lange Liste scrollen zu müssen) aber ich denke darauf lässt sich niemand ein ;)

Es wird Dir keiner verbieten können das einfach selbst in ein Internal zu schreiben:
{$defs{"<devicename>"}->{ip} = "<html><a href='http://".ReadingsVal("<devicename>","ip","none")."/' target='_blank'>".ReadingsVal("<devicename>","ip","none")."</a></html>"}
 :)




flummy1978

Zitat von: TomLee am 24 Januar 2025, 01:39:55Es wird Dir keiner verbieten können das einfach selbst in ein Internal zu schreiben:
Nach huch, das ist doch mal ne Idee  ::) ..... ich wusste gar nicht dass das überhaupt geht, aber müsste das nicht ins Modul rein ? (Sprich ich verliere es jedesmal beim Update (sehe keine notwendigen Updates?) Oder gibt es noch einen anderen Weg?

VG
Andreas

Beta-User

Zitat von: flummy1978 am 24 Januar 2025, 02:03:15Nach huch, das ist doch mal ne Idee  ::) ..... ich wusste gar nicht dass das überhaupt geht, aber müsste das nicht ins Modul rein ? (Sprich ich verliere es jedesmal beim Update (sehe keine notwendigen Updates?) Oder gibt es noch einen anderen Weg?
Wir hatten so eine ähnliche Diskussion irgendwann mal; soweit ich das im Kopf habe, resultiert daraus das Internal "MQTT2_FHEM_Server_CONN" - da steht (ungeprüft: nur bei M2S und als Teil des Inhalts) jeweils die aktuelle IP mit drin.

Du kannst so ein Internal schon per userReadings-Eintrag generieren, aber dann bitte sauber triggern ;) ; wenn du es richtig machst, ist dann auch jeweils der aktuelle Wert drin, auch wenn du mal M2C als IO verwendest... (Vielleicht den Namen so wählen, dass das im Kontext von "MQTT2_FHEM_Server_CONN" erscheint).

Über den Weg devStateIcon kann man streiten, aber auf der anderen Seite ist es doch auch nicht "falsch", wenn man - egal wo - die Info hat, ob das Gerät da ist. Das mit dem IP-Klick ist dann nur ein Feature, das keinen zusätzlichen Platz verschwendet.

Und für andere User bzw. "das Tablet in der Küche" würde ich eh die Frage stellen, ob man auf floorplan setzen sollte (oder nicht lieber sowas wie FHEMapp).
Das Weglassen verhindert aber nicht, dass andere mit Raten weiter kommen könnten, wenn man keine Passwörter auf den Devices setzt ;) .

Na ja, meine 2ct: Für admin-Zwecke würde ich dann lieber schlicht die Adresse abtippen, wenn der Klick nicht gewünscht ist...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Zitat von: Beta-User am 24 Januar 2025, 07:35:32Wir hatten so eine ähnliche Diskussion irgendwann mal; soweit ich das im Kopf habe, resultiert daraus das Internal "MQTT2_FHEM_Server_CONN" - da steht (ungeprüft: nur bei M2S und als Teil des Inhalts) jeweils die aktuelle IP mit drin.

Du kannst so ein Internal schon per userReadings-Eintrag generieren, aber dann bitte sauber triggern ;) ; wenn du es richtig machst, ist dann auch jeweils der aktuelle Wert drin, auch wenn du mal M2C als IO verwendest... (Vielleicht den Namen so wählen, dass das im Kontext von "MQTT2_FHEM_Server_CONN" erscheint).

So leid es mir tut, aber mit den ersten beiden Sätzen bin ich hoffnungslos überfordert :-\ Da ich nicht wusste, dass man Internals überhaupt außerhalb des Moduls ansprechen kann, weiss ich natürlich nicht, wie es im besten Falle "sauber getriggert und entsprechend vernünftig gelöst" aussehen würde.

Aber zum Rest kann ich natürlich defintiv was sagen:
Bitte nicht falsch verstehen - der Weg über das devStateIcon ist für mich ganz sicher nicht falsch, oder dergleichen. Ich nenne nur die Gründe, die bei mir dagegen sprechen. Ich habe z.B. einige devStateIcon die aus mehreren Werten dargestellt werden, aber eben nicht alle im Perl Modus (Tue mir da manchmal noch etwas schwer). Der zusätzlich benötigte Platz ist dann natürlich kein großer, aber er ist nunmal da.
Ich überlege gerade, ob man es bsw irgendwie hinbekommen könnte das icon abhängig von der Verbindung zu verändern. Wenn anderes Icon da steht, dann ist klar, dass die Verbindung weg ist.

ZitatDas Weglassen verhindert aber nicht, dass andere mit Raten weiter kommen könnten, wenn man keine Passwörter auf den Devices setzt ;)
Das ist etwas, dass ich sowohl mit Firewallregeln, als auch mit PWs auf den Devices erschlagen hab. Mir ist durchaus bewusst, dass es kritisch ist, wenn die Geräte zugängig sind, egal auf welcher Art.

VG
Andreas

Beta-User

Vielleicht noch kurz: userReadings ist in der commandref beschrieben, auch, wie man da trigger definiert.

Was da nicht explizit steht: Man kann beliebigen Perl-Code innerhalb des userReadings-Aufrufs ausführen (abgesehen von ein paar "verbotenen" Kommandos wie setreading), also auch Internals schreiben etc. pp. Man muss noch nicht mal das definierte userReading "befüllen", sondern kann einfach per "return;" (evtl. braucht es auch ein "return undef;") beenden, ohne das "Reading" (das es dann nie gibt) neu zu setzen.

Aber auch da brauchst du Perl, von daher ist imo der Weg über devStateIcon (-Perl) eigentlich der bessere.

Falls du Beispiele für bedingte Darstellungen suchst: Es gibt nicht nur sehr viele Codes in der attrTemplate-File zu MQTT2_DEVICE, sondern z.B. auch die utils zu ZWave-attrTemplate und einen Thread von mir mit (u.A.) devStateIcon-Code für Homematic (CUL_HM, https://forum.fhem.de/index.php?topic=97430.0).
Vielleicht hilft dir das weiter im Lernen :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Vielen Dank für die Beispiele bzw die allgemeinen Hinweise.
Zitat von: Beta-User am 24 Januar 2025, 10:43:32Vielleicht hilft dir das weiter im Lernen :)
Nicht nur vielleicht .... definitiv wird das wieder helfen  :)

VG Andreas

p.s. Ich denke damit hat sich der "Wunsch" dann erledigt... ich denke mal, wenn von einem Developer schon was dagegen spricht, werden andere sicher noch mehr Gründe haben  ;)

Beta-User

Zitat von: flummy1978 am 24 Januar 2025, 12:04:33p.s. Ich denke damit hat sich der "Wunsch" dann erledigt... ich denke mal, wenn von einem Developer schon was dagegen spricht, werden andere sicher noch mehr Gründe haben  ;)
Eigentlich wollte ich mich ja gar nicht klar positioniert haben, aber damit das klarer wird: Mir ist das letztlich fast egal. Imo ist es überflüssig, und ich bin auch eher bei martinp876 - man sollte die Internals nicht überfrachten und eher weniger wie mehr anzeigen (https://forum.fhem.de/index.php?topic=140062.0).
Ist aber zum Teil auch eine Geschmacksfrage :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

flummy1978

Zitat von: Beta-User am 24 Januar 2025, 12:41:41Eigentlich wollte ich mich ja gar nicht klar positioniert haben, aber damit das klarer wird........

Ich weiss nicht ob ich das gerade falsch interpretiere, aber nur kurz zur Aufklärung: Mein Hinweis mit "damit hat sich das eigentlich erledigt" war ganz und gar nicht böse oder sonst was gemeint im Gegenteil:

Du hast mir mit Deiner Darstellung, den Links und auch der PDF von Martin genug Beispiele gebracht warum es KEINEN Sinn macht es zu implementieren, mir aber gleichezeitig (mit @TomLee) einen Weg aufgezeigt wie es trotzdem gehen würde. Nun liegt es an mir es selbst umzusetzen oder eben auch nicht wenn ich es haben möchte  ;)
Am Ende kann ich das in der Code Ecke publik machen und jeder kann es nutzen, wie er möchte. Aber das Ganze eben OHNE es für alle anderen zu überladen, die es vielleicht nie brauchen :)

VG
Andreas