Neues Modul - 74_Unifi - Für den Ubiquiti Networks (UBNT) - Unifi Controller

Begonnen von rapster, 23 August 2015, 02:12:04

Vorheriges Thema - Nächstes Thema

markus_fhem

So als Anregung: Ich habe es bei mir noch weiter entwickelt, indem im Flur ein Tablet mit ftui hängt, an dem sich die Gäste per self-service ihren Voucher selbst ziehen können. Sorgt beim ersten Mal immer wieder für staunende Gesichter. Und ab dem zweiten Besuch gehen alle da wie selbstverständlich dran.

Gesendet von meinem SM-G960F mit Tapatalk


Black7king

Zitat von: markus_fhem am 20 Dezember 2018, 19:07:12
So als Anregung: Ich habe es bei mir noch weiter entwickelt, indem im Flur ein Tablet mit ftui hängt, an dem sich die Gäste per self-service ihren Voucher selbst ziehen können. Sorgt beim ersten Mal immer wieder für staunende Gesichter. Und ab dem zweiten Besuch gehen alle da wie selbstverständlich dran.

Gesendet von meinem SM-G960F mit Tapatalk

kannst du mal bitte zeigen wie des aussieht? und ein Beispiel?

ChrisW

okay coole idee :) Kann man den Voucher auch dauerhaft speichern ? Meine 2-3 Stammgäste sollen möglichst sofort rein kommen ohne etwas zu machen ;)
Raspberry PI3 mit allem möglichen.

markus_fhem

Zitat von: Black7king am 20 Dezember 2018, 19:48:33
kannst du mal bitte zeigen wie des aussieht? und ein Beispiel?

Klar doch, gerne.

Von außen:
Ein Tablet in einem einfachen IKEA-Bilderrahmen, der die nötige Tiefe hat. Und dahinter direkt die dauerhafte Stromversorgung.

Von innen:
In einem dummy werden für unterschiedliche Gültigkeiten (pro Dauer ein reading) einige Voucher als Komma-separierte Liste vorgehalten, die dann vom Tablet aus über Notify und diese Funktion abgerufen werden können. Dieser Weg, da das Echtzeitabrufen der Voucher zu langsam war.

Das Generieren der Voucher passiert in einem externen php-Script. Inzwischen müsste das auch über das Modul selbst möglich sein, ich habe es aber nie umgebaut.

## Unifi-Voucher für Gäste-WLAN anfordern
sub Code_Anfordern($){

my ($hash) = @_;

my $defaultzeit = ReadingsVal("VoucherZeit.dum","default",1); ## In Reading definierten default-Wert für Voucher-Dauer holen
my $zeit = ReadingsVal("VoucherZeit.dum","state",$defaultzeit); ## Gewählte Voucher-Dauer abfragen

my $voucherlist = ReadingsVal("VoucherCode.dum", $zeit, 0); ## passende Vouchers aus Reading auslesen und einenen Code in State schreiben

my @vouchers = split ( /\,/, $voucherlist );

my $voucherzahl = scalar @vouchers;
fhem "set test.dum $voucherzahl";

my $voucher = splice (@vouchers, 0, 1);

if ($voucherzahl == 1) {
  $voucherlist = qx(php /usr/local/src/Voucher.php $zeit); ## neue Vouchers für gewählte Gültigkeit holen, wenn nur noch einer übrig ist
} else {
  $voucherlist = join ',', @vouchers;
}
fhem "set VoucherCode.dum $voucher";
fhem "defmod at_VoucherZeitDefault at +00:03:00 set VoucherZeit.dum $defaultzeit"; ## gewählte Voucher-Dauer nach Zeit x auf default zurücksetzen
fhem "setreading VoucherCode.dum $zeit $voucherlist";

}

markus_fhem

Zitat von: ChrisW am 21 Dezember 2018, 11:13:26
okay coole idee :) Kann man den Voucher auch dauerhaft speichern ? Meine 2-3 Stammgäste sollen möglichst sofort rein kommen ohne etwas zu machen ;)
Gib Ihnen Voucher, die eine entsprechend lange Gültigkeit haben. Z.B. läuft mein Firmenhandy auch im Gäste-WLAN mit einer Voucher-Dauer von einem Jahr. Und zudem können Voucher auch verlängert werden, bevor sie abgelaufen sind.

Wuehler

ZitatInzwischen müsste das auch über das Modul selbst möglich sein
Korrekt. Dazu gibt es das Attribut VoucherCache mit passendem Reading für den nächsten freien Voucher eines Caches. Außerdem passende get VoucherList-Abfragen.
Einfach mal ausprobieren. In der Commandref sollte es beschrieben sein. Und wenns missverständlich ist einfach melden.

hoppel118

#831
Hallo Leute,

schön, dass es auch für das Unifi Equipment ein FHEM Modul gibt. Ich habe einige Komponenten, die ich nun gern einbinden möchte.


  • 1x Unifi Security Gateway
  • 2x Unifi Switch US 8 150W
  • 3x Unifi UAP AC Pro

Gibt es einen Wiki-Beitrag, der beschreibt, was möglich ist und was zu tun ist, um alles sauber einzubinden?

Irgendwie finde ich den gerade nicht.


  • Mein Unifi Controller läuft auf der letzten LTS Version: 5.6.40
  • Ihr seid hier anscheinend häufig (alle?) schon auf Version: 5.9.x

Sind dadurch irgendwelche Probleme zu erwarten?

Mein Ziel ist erstmal nur die Nutzung von "Presence" für zwei Smartphones. Als erstes habe ich im Controller einen neuen User mit Lesezugriff eingerichtet. Dann habe ich den Controller wie folgt definiert:

define UnifiController Unifi localhost 8443 <user> <password>

Neben dem Controller wurden noch meine beiden Switche eingerichtet. Das Security Gateway und die drei Access Points fehlen. Ist das so korrekt?


EDIT: Anscheinend funktioniert das so nicht. Mein FHEM WebUI zeigt mir nun in regelmäßigen Abständen "Connection lost, trying a reconnect every 5 seconds." an. Im Logfile kann ich einen Disconnect nicht nachvollziehen. Es gibt keine Einträge, alles sieht gut aus. Kennt das Problem jemand? Kann das mit der LTS-Version 5.6.40 zusammenhängen?


Danke und viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Wuehler

Hallo und Willkommen im Unifi-Thread.

einen Wiki-Artikel zum Modul gibt es bisher nicht. Bisher hat sich noch niemand gefunden ihn zu beginnen.
Allerdings ist dieser Thread im Großen und Ganzen auch der einzige Thread zum Modul (plus den kurzen Thread zum Unifi-Switch-Modul), so dass man bei geschickter Forumssuche gute Beispiele finden kann.

Für dich als neuer User des Moduls zwei Hinweise:
1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf.  ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.
2. Bei dir laufen fhem und Unifi vermutlich auf demselben RasPi (oder ähnlich). Wenn es Verbindungsprobleme gibt schau dir mal die Auslastung mit dem Befehl top an. Bei deinem define fragt fhem alle 30 Sekunden alle möglichen Infos ab. Das verursacht auf dem einen Kern recht viel Last und kann dazu führen, dass die Kommunikation zu lange dauert. Dann ggf. im define das Interval hoch setzen oder besser auf zwei RasPi verteilen.

Deine LTS-Version sollte eigentlich keine Probleme bereiten.

Zu PRESENCE gab es vor kurzem in diesem Thread einen best practice. Musst da mal weiter vorne schauen.

Deine APs sind auch angelegt, allerdings nicht als eigene devices sondern als Readings (beginnen mit -AP_) im Controller-Device. Den Switches habe ich vor kurzem ein eigenes Modul gegönnt, da diese je Port einige Readings hatten und ausserdem einige Funktionen (die Switch-Funktionen auf Controller-Ebene werde ich irgendwann auch ausbauen). Für das USG gab es bisher keine speziellen Anforderungen. Ein paar Readings dazu gibt es auch im Controller-Device (beginnen mit -UC_).

Viel Erfolg bei der weiteren Einrichtung,
Dirk

sledge

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59

1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf.  ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.


Guter Hinweis - war mir doch glatt durchgerutscht. Direkt mal gesetzt und sämtliche PRESENCE-Devices angepasst... Wie immer Danke!
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

hoppel118

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Hallo und Willkommen im Unifi-Thread.

einen Wiki-Artikel zum Modul gibt es bisher nicht. Bisher hat sich noch niemand gefunden ihn zu beginnen.
Allerdings ist dieser Thread im Großen und Ganzen auch der einzige Thread zum Modul (plus den kurzen Thread zum Unifi-Switch-Modul), so dass man bei geschickter Forumssuche gute Beispiele finden kann.

Hallo Dirk, danke erstmal für die herzliche Begrüßung. OK, dann werde ich mich mal auf die Suche in diesen beiden Threads begeben.

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Für dich als neuer User des Moduls zwei Hinweise:
1. setze das Attribut deprecatedClientNames auf 0, dann werden deine clients ggf. anders, aber icht mehr auf die alte teilweise verwirrende Art, benannt. Spart dir später ggf.  ein Umbenennen in PRESENCE oder notifies, wenn ich das Standardverhalten ändere.

OK, das habe ich direkt mal gemacht. Danke für den Hinweis.

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
2. Bei dir laufen fhem und Unifi vermutlich auf demselben RasPi (oder ähnlich). Wenn es Verbindungsprobleme gibt schau dir mal die Auslastung mit dem Befehl top an.

Ich habe einen XEON-Server (E3-1240L-v5) mit Supermicro Mainboard (X11SSH-CTF) mit 64GB ECC RAM, SSDs für das OS, ein ZFS Raid-Z2 mit ordentlich Speicher und eine Digital Devices MaxS8 zum TV schauen. ;)

Als OS verwende ich Openmediavault4 (Debian Stretch). Neben FHEM und Homebridge (beides läuft direkt auf dem System) betreibe ich folgende Docker Container: Portainer, Netdata, Unifi, TVHeadend und Emby. Also nichts wildes. Das läuft auch soweit alles einwandfrei.   

Meine CPU dümpelt gerade auf ca. 5% herum. Es läuft LiveTV auf einem meiner Kodi Clients. An einer Überlastung meines Servers kann es somit nicht liegen.

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Bei deinem define fragt fhem alle 30 Sekunden alle möglichen Infos ab. Das verursacht auf dem einen Kern recht viel Last und kann dazu führen, dass die Kommunikation zu lange dauert. Dann ggf. im define das Interval hoch setzen oder besser auf zwei RasPi verteilen.

Mir ist gerade aufgefallen, dass bei meinem define der Interval und die SiteID fehlen. Ich habe mein define nun wie folgt angepasst:

define UnifiController Unifi localhost 8443 <user> <password> 30 default

Ist 30 Sekunden das Default-Interval?

Wie dem auch sei, das hat leider nichts gebracht. Es hängt aber tatsächlich mit dem Interval zusammen. Ich habe Interval 60 und 600 getestet. Die Meldung "Connection lost, trying a reconnect every 5 seconds." erscheint immer genau zum Interval. Das hat also leider auch nichts gebracht.

Während der "Connection lost..." Meldung erscheint "perl" immer sehr weit oben in "top". Es lastet die CPU aber auch nur ca. 3-6% aus. Daran kann es nicht liegen.

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Deine LTS-Version sollte eigentlich keine Probleme bereiten.

OK, gut zu wissen. Dann belasse ich es erstmal bei der Version.

Zitat von: Wuehler am 27 Dezember 2018, 01:32:59
Deine APs sind auch angelegt, allerdings nicht als eigene devices sondern als Readings (beginnen mit -AP_) im Controller-Device. Den Switches habe ich vor kurzem ein eigenes Modul gegönnt, da diese je Port einige Readings hatten und ausserdem einige Funktionen (die Switch-Funktionen auf Controller-Ebene werde ich irgendwann auch ausbauen). Für das USG gab es bisher keine speziellen Anforderungen. Ein paar Readings dazu gibt es auch im Controller-Device (beginnen mit -UC_).

OK, habe mir die Readings im Controller-Device gerade mal etwas genauer angesehen. Stimmt, da sehe ich Readings für mein USG, meine USWs und meine UAPs. Alles klar.

Danke schonmal für die Unterstützung! Falls hier noch jemand eine Idee hat, mich auf die richtige Fährte zu bringen, immer her damit. ;)

Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Wuehler

Moin Hoppel,

ZitatIst 30 Sekunden das Default-Interval?
Ja, 30 Sekunden ist default. Aber bei der Rechnerleistung sollte es da keine Probleme geben. Beides auf einem RasPi geht auch, führt aber manchmal zu hohen Prozessorlasten.

Ich habe noch nicht verstanden, wann es funktioniert und wann nicht mehr. Geht es dann dauerhaft nicht, oder es geht eigentlich, aber im Log gibt es die "reconnect"-Meldung?
Außerdem kommt die Meldung nicht aus dem Unifi-Modul direkt. Kannst du (mit Attribut verbose auf 5) mal einen Log-Auszug posten.

Viele Grüße,
Dirk

hoppel118

Hallo Dirk,

die "reconnect"-Meldung taucht nicht im Logfile auf. Es handelt sich dabei einfach um die Meldung im FHEM WebInterface, siehe unten im angehängten Screenshot. Bei mir ist grundsätzlich "attr global verbose 3" gesetzt. Nun habe ich mal "attr UnifiController verbose 5" am Controller-Device gesetzt. Meine Unifi-Config sieht somit nun wie folgt aus:

define UnifiController Unifi localhost 8443 xxxx xxxx 30 default
attr UnifiController deprecatedClientNames 0
attr UnifiController icon it_network
attr UnifiController room Netzwerk
attr UnifiController verbose 5
define switch_base UnifiSwitch switch_base
attr switch_base room Netzwerk
define FileLog_switch_base FileLog ./log/switch_base-%Y.log switch_base
attr FileLog_switch_base logtype text
attr FileLog_switch_base room Netzwerk
define switch_office UnifiSwitch switch_office
attr switch_office room Netzwerk
define FileLog_switch_office FileLog ./log/switch_office-%Y.log switch_office
attr FileLog_switch_office logtype text
attr FileLog_switch_office room Netzwerk


Hier wie gewünscht das Logfile dazu:


  • um 22:26:34 habe ich den fhem service gestartet, im WebInterface habe ich mich zu diesem Zeitpunkt in meinem Raum "Beleuchtung" befunden, die "reconnect"-Meldung ist nicht erschienen
  • um ca. 22:27:15 habe ich im WebInterface in den Raum "Netzwerk" gewechselt
  • um 22:27:36, um 22:28:06 und 22:28:37 habe ich dann die "reconnect"-Meldung im WebInterface gesehen

https://pastebin.com/Pg9jusZL

Die "reconnect"-Meldung taucht also nur auf, wenn ich mich im FHEM WebInterface in dem von mir definierten Raum "Netzwerk" befinde. Wenn ich auf einen anderen Raum im FHEM WebInterface wechsle, taucht die Meldung plötzlich nicht mehr auf. Das habe ich eben gerade herausgefunden. In dem Raum "Netzwerk" befinden sich ausschließlich meine Unifi-Definitionen, siehe Konfiguration oben. Sobald ich den Raum "Netzwerk" im WebInterface anklicke, erscheint alle 30 Sekunden im Gleichtakt mit dem Interval die "reconnect"-Meldung.

Womit kann das denn Zusammenhängen?
Siehst du da irgendwelche Fehler?

Meiner Ansicht nach sieht das alles gut aus.

Danke für deine Unterstützung.


Viele Grüße Hoppel
Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

Wuehler

Moin,

OK, jetzt verstehe ich das Problem  :)
Dazu müsste FhemWeb zunächst analysiert werden, nicht das Unifi-Modul. Kannst du bitte unter Frontends/Fhemweb einen neuen Thread dazu eröffnen und ihn mir per pm senden. Dann klinke ich mich ein. Bei mir selbst kann ich das nicht nachvollziehen.
Ich habe als Vermutung, dass es daran liegt, dass das Unifi-Modul viele http-requests absetzt und daher FhemWeb keine Ressourcen für sein Polling hat.
Da auch das Modul freezemon Unifi als mögliche Quelle für freezes anzeigt wäre das ein weiterer Hinweis das Design des Unifi-Moduls zu überdenken.
Wäre schön, wenn wir das mit FhemWeb klären könnten.

Viele Grüße,
Dirk

hoppel118

Server: Openmediavault, XEON E3-1240L-v5, Supermicro X11SSH-CTF, 64GB ECC RAM, SSD, RAID-Z2
Homebridge | Alexa | Yowsup
Homematic | HomeConnect | MQTT | Philips Hue | Sonos | Unifi Network & Protect | vbus | Xiaomi

wagenkna

Hallo Wuehler,

vielen Dank für das super Modul!
Ich habe allerdings seit heute Nachmittag das Problem, das dass Modul zwar auf den Unifi Server connectetd, aber dann nur Fehler bringt. Sprich es wird keine Anwesenheit vom Unifi ins Fhem übertragen. Ich habe versucht einen weiteren AP AC Pro zu installieren. Dabei "verabschiedete sich der schon angemeldete AP, der seit ca. 2 Jahren lief....

Ich habe hier das List zum UNIfi gezogen:
Internals:
   CHANGED   
   DEF      xxx.xxx.xxx.xxx 8443 crypt:59120201045f5c5e crypt:4030080038625a745c561502372d695706632202
   NAME       UNIFI_Accesspoint
   NOTIFYDEV  global
   NR         1311
   NTFY_ORDER 50-UNIFI_Accesspoint
   STATE      connected
   TYPE       Unifi
   VERSION    3.0.4
   .attraggr:
   .attreocr:
     state
   .attreour:
     state
   .attrminint:
   READINGS:
     2019-01-14 21:32:48   -AP_xxx.xxx.xxx.80_clients 0
     2019-01-14 21:32:48   -AP_xxx.xxx.xxx.80_essid
     2019-01-14 21:32:48   -AP_xxx.xxx.xxx.80_locate unknown
     2019-01-14 21:32:48   -AP_xxx.xxx.xxx.80_state error
     2019-01-14 21:32:48   -AP_Unifi_gateway_clients 0
     2019-01-14 21:32:48   -AP_Unifi_gateway_locate unknown
     2019-01-14 21:32:48   -AP_Unifi_gateway_state error
     2019-01-14 21:35:56   -UC_events      0 (last 24h)
     2019-01-14 21:35:56   -UC_newClients 
     2019-01-14 21:35:56   -UC_unarchived_alerts 0
     2019-01-14 21:35:56   -UC_wlan_accesspoints 0
     2019-01-14 21:35:56   -UC_wlan_guests 0
     2019-01-14 21:35:56   -UC_wlan_state  error
     2019-01-14 21:35:56   -UC_wlan_users  0
     2019-01-14 21:35:56   -WLAN_FRITZ_Box_Gastzugang_state enabled
     2019-01-14 21:35:56   -WLAN_Ramsau_state enabled
     2019-01-14 21:35:56   -WLAN_ZUHAUSE_state enabled
     2019-01-14 21:34:38   state           connected
   accespoints:
   alerts_unarchived:
   clients:
   events:
   helper:
     password   crypt:4030080038625a745c561502372d695706632202
     username   crypt:59120201045f5c5e
   hotspot:
     voucherCache:
     vouchers:
   httpParams:
     header     Cookie: unifises=fOy7ONcDTJOoTRmZytAbe1JnqcRIzn4k;\r\nCookie: csrf_token=NWid6KwgDBjj2z5sQXKixHtdKI5a1sUc;
     ignoreredirects 1
     loglevel   5
     method     POST
     noshutdown 0
     timeout    5
     hash:
     sslargs:
       SSL_verify_mode 0
   unifi:
     CONNECTED  connected
     connectedClients
     deprecatedClientNames 0
     eventPeriod 24
     interval   30
     updateStartTime 1547498078
     url        https://xxx.xxx.xxx.xxx:8443/api/s/default/
     version    4
   updateDispatch:
   wan_health:
     gw_mac     f0:9f:c2:c3:53:e9
     gw_name    Unifi_gateway
     gw_system-stats
     gw_version 4.3.33.4936086
     num_adopted 1
     num_disconnected 1
     num_gw     0
     num_pending 0
     status     error
     subsystem  wan
   wlan_health:
     num_adopted 1
     num_ap     0
     num_disabled 0
     num_disconnected 1
     num_guest  0
     num_pending 0
     num_user   0
     rx_bytes-r 0
     status     error
     subsystem  wlan
     tx_bytes-r 0
   wlans:
     5902f0f1bc58f24b0c43ca8c:
       _id        5902f0f1bc58f24b0c43ca8c
       dtim_mode  default
       dtim_na    1
       dtim_ng    1
       mac_filter_policy deny
       name       Ramsau
       security   wpapsk
       site_id    59028075577ab8fab28dfaed
       usergroup_id 59028077577ab8fab28dfaf4
       wep_idx    1
       wlangroup_id 59028077577ab8fab28dfaf5
       wpa_enc    ccmp
       wpa_mode   wpa2
       x_iapp_key 18f62241f4bf7574e9ccd283af3ba01c
       bc_filter_list:
       mac_filter_list:
       schedule:
     5902f6e0bc58f24b0c43cb0b:
       _id        5902f6e0bc58f24b0c43cb0b
       dtim_mode  default
       dtim_na    1
       dtim_ng    1
       group_rekey 3600
       mac_filter_policy deny
       minrate_na_beacon_rate_kbps 6000
       minrate_na_data_rate_kbps 6000
       minrate_na_mgmt_rate_kbps 6000
       minrate_ng_beacon_rate_kbps 1000
       minrate_ng_data_rate_kbps 1000
       minrate_ng_mgmt_rate_kbps 1000
       name       FRITZ!Box Gastzugang
       security   wpapsk
       site_id    59028075577ab8fab28dfaed
       usergroup_id 59028077577ab8fab28dfaf4
       wep_idx    1
       wlangroup_id 59028077577ab8fab28dfaf5
       wpa_enc    ccmp
       wpa_mode   wpa2
       x_iapp_key 613bbd3e1337648bdddc44e3b40b51ce
       bc_filter_list:
       mac_filter_list:
       schedule:
     590c77d3577ae0e0303a6576:
       _id        590c77d3577ae0e0303a6576
       dtim_mode  default
       dtim_na    1
       dtim_ng    1
       mac_filter_policy deny
       name       ZUHAUSE
       security   wpapsk
       site_id    59028075577ab8fab28dfaed
       usergroup_id 59028077577ab8fab28dfaf4
       wep_idx    1
       wlangroup_id 59028077577ab8fab28dfaf5
       wpa_enc    ccmp
       wpa_mode   wpa2
       x_iapp_key 5972f9da81c062f0aa11d2a55799e457
       bc_filter_list:
       mac_filter_list:
       schedule:
   www_health:
     gw_mac     f0:9f:c2:c3:53:e9
     status     error
     subsystem  www
Attributes:
   deprecatedClientNames 0
   event-on-change-reading state
   event-on-update-reading state
   room       System
   verbose    5


Gelegentlich taucht eine Fehlermeldung im LogFile auf

UNIFI_Accesspoint (Unifi_Login_Receive) - executed.
2019.01.14 20:52:21 5: UNIFI_Accesspoint (Unifi_Login_Receive) - Error while requesting https://xxx.xxx.xxx.xxx:8443/api/login - https://xxx.xxx.xxx.xxx:8443/api/login: Can't connect(2) to https://xxx.xxx.xxx.xxx:8443:  SSL connect attempt failed error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert unexpected message
2019.01.14 20:52:21 5: UNIFI_Accesspoint (Unifi_Login_Receive) - Connect/Login to Unifi-Controller failed. Will try again after interval...
2019.01.14 20:52:21 3: FHEM2FHEM device opened (Remote_TRX)
2019.01.14 20:52:23 5: UNIFI_Accesspoint (Unifi_Notify) - executed.


Der Unifi Controller läuft auf dem gleichen Raspi 3, wie auch das Fhem,
Interessanterweise wird der neue AP AC nicht im Modul aufgeführt. xxx.xxx.xxx.81
Das Gateway ist tatsächlich nicht vorhanden.
Beide APs haben die gleiche Softwareversion :3.9.19.8123

Update Fhem und Raspi, neustart etc. habe ich auch schon probiert....

Kannst du erkennen, warum das Modul nicht mehr funzt??

Besten Dank für deine Unterstützung

winterliche Grüße

Axel
Homematic mit CCU2, Fensterkontakt, Thermostaten, Steckdosen, Regen.-Bewegung.-Wassermelder (76) Devices)
Raspberry2 und 3 Mit KNX, OWL, Fritzbox, Unifi, Luftmessungmodul