Bedingung mit URL Aufruf und FHEM Command

Begonnen von huhu, 08 Januar 2021, 14:07:25

Vorheriges Thema - Nächstes Thema

huhu

Hallo zusammen,
ich versuche folgendes Statement:

+*01:00:00 {if(Value("Automatik_UnifiSSID") eq "on" && ReadingsVal("UnifiController","-AP_Dachgeschoss_state","") eq "ok" && ReadingsVal("UnifiController","-AP_Dachgeschoss_essid","") eq "Wlan1,Wlan2,Wlan3" && ReadingsVal("UnifiController","Zirkulationspumpe","") eq "connected" && ReadingsVal("UnifiController","Zirkulationspumpe_essid","") eq "Wlan1") { GetHttpFile("192.168.1.48", "/cm?cmnd=Backlog%20ap%201") } {fhem ("set telebot_fhem message Wifi changed Zirkulationspumpe") } }

1x pro Stunde wird geprüft mit welcher SSID das Gerät verbunden ist. Da ich in den WLAN Clients keinen Accesspoint zuweisen kann, prüfe ich die Verbindung und ändere das WLAN mittels GetHttpFile (hier eine Tasmota Steckdose). Soweit funktioniert das, allerdings möchte ich darüber eine Benachrichtigung über Telegram erhalten.

Das hinzugefügte
{fhem ("set telebot_fhem message Wifi changed Zirkulationspumpe") }
ignoriert die Bedingung, so dass jede Stunde die Nachricht ohne Prüfung gesendet wird.

Wie müsste das Statement abgeändert werden, dass GetHttpFile und die Nachricht nur bei erfüllen der Bedingung gesendet wird?


Besten Dank :-)

MadMax-FHEM

#1
Naja, Perl lernen ;)


if(Bedingung[en]){führe aus}


D.h. dein Telegram-Senden muss halt mit in {führe aus} ;)

Je nachdem wo/wie du es "eingibst" eben den fhem-Befehl mit einem oder zwei Strichpunkten getrennt INNERHALB der geschweiften Klammern des "if-führe-aus-Teils"...


if(Bedingung[en]){führe das aus; führe was anderes auch noch aus}


Anmerkung: GetHttpFile ist "blocking". D.h. fhem "steht" solange bis der Befehl abgearbeitet ist. Mag meist schnell gehen. Aber wenn die Gegenstelle mal nicht mag auch durchaus dauern... Besser: HttpUtils NonBlockingGet...

EDIT: Da du Unifi nutzt, das UnifiClient-Modul kennst du? Dort gibt es ein Reading "essid". D.h. ein notify "darauf" und die kannst prüfen, ob der Client connected ist und mit welcher ssid oder auch mit welchem AP (oder habe ich deine ganze Abfragerei falsch interpretiert?) und es gibt doch beim Unifi-Client ein "disconnect" Client woraufhin er sich einen neuen AP sucht (bzw. was macht dein http-Aufruf? / aber egal, du kannst ja auch den aufrufen dann)... Dann kannst du sofort reagieren, wenn sich der Client "falsch verbindet" und nicht alle Stunde prüfen. Und: warum willst du das? Ist es nicht egal womit verbinden, hauptsache verbunden?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

huhu

Hallo Jürgen,

danke für den Hinweis.
Ich hatte es so schon versucht, allerdings falsch?

if(Bedingung[en]) { GetHttpFile("192.168.1.40", "/cm?cmnd=Backlog%20ap%201"); fhem("set telebot_fhem message Wifi changed Stecker10") }  }
und auch ohne fhem

if(Bedingung[en]) { GetHttpFile("192.168.1.40", "/cm?cmnd=Backlog%20ap%201"); set telebot_fhem message Wifi changed Stecker10 }  }

Anders als sonst ist, dass ich statt mehrerer FHEM Befehle nun noch den URL Aufruf haben möchte...


Ja genau, um die Clients auf den richtigen AP zu lenken. Durch den Reconnect über das Unifi Modul verbindet sich der Client wieder mit dem "Roamed WLAN", welches auf allen Etagen anliegt. Ich habe pro Etage zusätzlich eine eigene SSID angelegt, damit die Devices sich damit verbinden. Im Unifi Controller kann man noch mit Minimum RSSI ect arbeiten, das funktioniert aber nicht so optimal. Es kann daher sein, dass einige Devices mit dem AP auf einer anderen Etage verbunden sind und dann nur 30% Signal haben, statt zb möglicher 90%. Der URL Aufruf wechselt vom 2. aufs 1. Wlan von Tasmota, dort sind beide hinterlegt.

Die Idee war, dass alle Devices immer mit dem bestmöglichen AP verbunden sind, sind sie es nicht, korrigiert fhem dies. Ich denke einmal am Tag reicht auch, es würde sowieso nur greifen nach einem Stromausfall oder wenn ein AP gepatcht wurde ect

Würde ich generell nur das jeweilige WLAN der Etage konfigurieren und der AP ist mal offline, wären die Geräte ebenfalls offline, so sind sie zumindest schwächer erreichbar.

huhu

Obwohl ich könnte mal testen, ob durch eine Trennung die Geräte sich mit dem stärksten Signal verbinden, wäre natürlich einfacher und vorallem bräuchte ich dann nicht die extra SSIDs...

MadMax-FHEM

#4
EDIT: übrigens: Joachim, nicht Jürgen ;)

Also ich hatte das ja auch mal vor... ;)

Bzw. bin ich vom autom. Trennen und neu Verbinden abgekommen...

Ich habe eine readingsGroup mit meinen "wichtigsten" ClientDevices bzw. eben für meine "wichtigen" Clients ein UnifiClient-Device welche ich dann in einer readingsGroup anzeigen lasse.

Dann eine Sub, wo ich für jeden Client "zugelassene" APs habe.
Ist ein Client bei einem "nicht zugelassenen" AP angemeldet wird es per Icon angezeigt.
Wenn ich auf das Icon klicke, wird ein "reconnect Client" ausgeführt.

Ab und an schaue ich da mal vorbei...
...und klicke rum.

Ansonsten lasse ich das Unifi-Netzerk und die Clients entscheiden.

Die Clients gehorchen auch nicht immer, daher eben keine automatische Neuverbindung, die würde ja dauern im Kreis laufen... ;)

Bei Interesse kann ich ja readingsGroup und myUtilsSub posten...

Äh: geht es jetzt? Wie geschrieben je nachdem WO du es eingibst musst du evtl. 2 Strichpunkte machen...

EDIT: und ich würde evtl. wirklich mal HttpUtilsNonBlockingGet anschauen! Oder es per fhem("\"wget -q url\"") non-blocking "auslagern".

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

tgv_boost

Servus,
ich will den Chat nicht kapern, aber beim Lesen des Codes ist mir eingefallen, ich hatte auch mal so ein Klammerkonstrukt ...

fhem.cfg ->
define ROT_02 notify JalousieROT:.* {\
if (ReadingsVal("JalousieROT","state","off") eq "off") {\
{ HttpUtils_NonblockingGet( { url=>"http://192.168.0.172:80/?=/Fauf", incrementalTimout=>"1", callback=>sub($$$) { my ($hash, $err, $data) = @_;; {if ("$err" eq "") {Log 1, "Fauf: ".("$data")}};; {if ("$err" ne "") {Log 1, " Err Fauf: ".("$err") ;; {fhem("sleep 60 ;; set JalousieROT off")}} }}} )};;\
}\
}

... und versuchte, das in ein Sub in myUtils.pm auszulagern.
fhem.cfg ->
define ROT_02 notify JalousieROT:.* {\
if (ReadingsVal("JalousieROT","state","off") eq "off") {\
{ HttpUtils_NonblockingGet( { url=>"http://192.168.0.172:80/?=/Fauf", incrementalTimout=>"1", callback=>sub(CBF_ROT_Fab) }};;\
}\
}

#99_myUtils.pm ->
sub
CBF_ROT_Fab($$$)
{
my ($hash, $err, $data) = @_;
if($data ne "")   
          {
  Log 1, "Fab: ".("$data")
  }
if($err ne "")   
          {
  { HttpUtils_NonblockingGet( { url=>"http://192.168.0.172:80/?=/Fab", incrementalTimout=>"1", callback=>sub($$$) { my ($hash, $err, $data) = @_;; {if ("$err" ne "") {Log 1, "ERR Fab: ".("$err")} } }} )}
                  }
}

Ich wollte noch einen Timeout realisieren, was aber als Klammerlösung meine geistige Leistungsfähigkeit übersteigt. Generell hätte die Sub-Lösung den Vorteil, dass sich weitere Funktionen eleganter einbauen lassen ließen.
Leider tut die Sub-Lösung nicht und so hab ich das Timeout Thema auf Eis gelegt.
Ist hier jemand, der das Auslagern einer Sub innerhalb eines HttpUtils_NonblockingGet schon mal gemacht hat und mit einem Beispiel weiterhelfen kann?
mit bestem Gruß
Walter

MadMax-FHEM

@tcg_boost: also bis auf dass es hier auch um einen HTTP-Aufruf geht und der (aktuell) auch noch anders gelöst ist, hat deine Frage ja GAR NICHTS hiermit zu tun, daher: bitte einen eigenen Thread aufmachen!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

huhu

Hallo Joachim (ups, das war keine Absicht ;) ),

ich wäre sehr an deiner Lösung interessiert! Hättest Du auch ein komplettes Beispiel, wie genau das mit dem HttpUtilsNonBlockingGet funktioniert? Ich hatte das mal vor ein paar Monaten schon für das Ambilight versucht, allerdings nicht hinbekommen.

Das trennen der Clients über den Unifi Controller bringt nichts, die Clients verbinden sich mit gleicher SSID und mit dem gleichen "schlechten" AP. Die Lösung von mir funktioniert nun prima, ist allerdings quick und dirty umgesetzt ;) Verwende ich aber nur für die fest eingebauten Smartdevices, die jeweils mit einem Backup WLAN ausgestattet sind. Es wäre schön gewesen, wenn der Hersteller der Accesspoints ebenfalls eine ähnliche Lösung anbieten würde, aber so ist das ja meistens...

Die beweglichen Clients, Handy, Notebook usw. roamen mittlerweile ganz gut das lasse ich auch so.

Viele Grüße
Dennis


MadMax-FHEM

Hallo Dennis,

ok, dann poste ich später mal meine Version.

Ist allerdings, wie ja geschrieben, mit dem reconnectClient.
Den kannst du ja mit deinem Url-Aufruf ersetzen...

Das mit nonBlockingGet hast du wohl falsch verstanden.
Ich habe "sowas" noch nicht genutzt, wollte nur darauf hinweisen, dass das was du verwendest "blockt" und wie es ohne "blocken" geht... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

#9
So hier als "RawDef":


defmod rgOverviewUnifiClients readingsGroup <Name>,<IP-address>,<access point>,<reconnect>,<RSSI>,<signal>,<channel>,<quality>,<state> TYPE=UnifiClient:ip,accesspoint,<{my_DisconnectClient($DEVICE)}@accesspoint>,rssi,signal,channel,satisfaction,fhem_state
attr rgOverviewUnifiClients valueStyle {my_SetUnifiClientStatusValueStyle($DEVICE, $READING)}


Und hier noch die beiden Subs:

Diese liefert ein "Icon" (audio_repeat) welches rot ist, wenn der Client am "falschen" AP angemeldet ist (siehe "Liste der Clients für den jeweiligen AP") und wenn der Name als fhem-Device existiert (oder so ähnlich, also in der Liste steht oder so, ist schon lange her, dass ich das "umgesetzt" habe und auch erst mal "nur" auf meinem Testsystem, da ist es u.U. nicht so "sauber" ;)  ) dann kann mal auch auf das Icon klicken und es wird dann eben "disconnect Client" ausgeführt.
Das müsstest du eben in deinen Aufruf ändern, wenn es halt mit dicsonnect/reconnect Client nicht geht...

sub my_DisconnectClient($)
{
  my ($Device) = @_;
  my $Name = ReadingsVal($Device,"fhem_clientName","n.a.");
  my $AP = ReadingsVal($Device,"accesspoint","n.a.");
  my @ClientListAP1 = ("Echo-Kueche","Echo-WC","Echo-Wohnzimmer");
  my @ClientListAP2 = ("Echo-Bad","Echo-Buero");
  my $ActClientFromList = "";
  my $found = "false";
  my $Ret = "%audio_repeat";
 
#  Log3(undef, 3, "my_DisconnectClient        Device: $Device    Name: $Name    AP: $AP");

  if($AP eq "AP-1")
  {
    foreach $ActClientFromList (@ClientListAP1)
{
  if($Name eq $ActClientFromList)
  {
    $found = "true";
  }
}
if($found ne "true")
{
      $Ret = "%audio_repeat\@red";
}
  }
  elsif ($AP eq "AP-2")
  {
    foreach $ActClientFromList (@ClientListAP2)
    {
  if($Name eq $ActClientFromList)
  {
    $found = "true";
  }
}
if($found ne "true")
{
      $Ret = "%audio_repeat\@red";
}
  }

  if($Name ne "n.a.")
  {
    # hier eben anpassen ;-)
    $Ret .= "%set UnifiController disconnectClient $Name";
  }
 
  return $Ret;
}


Diese hier "gestaltet" nur die readingsGroup etwas farblich usw. (kann also auch weg)

sub my_SetUnifiClientStatusValueStyle($$)
{
  my ($Device, $Reading)  = @_;
  my $StyleString = "style=\"color:black;text-align:right\"";
  my $Value = "n.a.";

  if($Reading eq "fhem_state")
  {
    $Value = ReadingsVal($Device, $Reading, "n.a.");
    if($Value eq "connected")
    {
  $StyleString = "style=\"color:green;text-align:right\"";
}
    else
    {
  $StyleString = "style=\"color:red;text-align:right\"";
}
  }
  elsif($Reading eq "satisfaction")
  {
    $Value = ReadingsNum($Device, $Reading, 0);
    if($Value > 90)
    {
  $StyleString = "style=\"color:green;text-align:right\"";
    }
    elsif($Value > 60)
    {
  $StyleString = "style=\"color:orange;text-align:right\"";
}
else
{
  $StyleString = "style=\"color:red;text-align:right\"";
}
  }

#  Log3(undef, 1, "my_SetHeatingStatusValueStyle Device: $Device      Reading: $Reading    Value: $Value      return: $StyleString");

  return $StyleString;
}


Ich habe etwas "gekürzt" (v.a. die Clientliste) und angepasst (AP-Namen).
Das musst du nat. auch noch für dich anpassen...
Ich hoffe dabei ist nichts "schief gelaufen" ;)

UND: wie geschrieben die readingsGroup zeigt eine Übersicht über UnifiClient-Devices! D.h. du musst für jeden Client der dir "wichtig" ist ein UnifiClient-Device anlegen...

Viel Spaß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Frank_Huber


MadMax-FHEM

Zitat von: Frank_Huber am 15 Januar 2021, 11:40:16
Genial,
Danke dass Du das teilst! :-)

Klar!

"Lebt" nicht fhem / das Forum / OpenSource / ... genau davon :)

Gruß, Joachim

P.S.: wenn's jemand verbessert gerne auch zurück. War für mich halt die "schnellste"/"einfachste" Lösung (und ist noch schwer "Testphase")...
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)