Mein FHEM läuft also lokal und ich bin auch schon das "https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM" Tutorial durch.
Nun möchte ich gerne einige vorhandene Hardware ansprechen/auslesen. Habe mich also umgesehen was so da wäre im Haushalt:
- HWg-STE: Ethernet thermometer (https://www.hw-group.com/device/hwg-ste), das kann man wohl über SNMP ausquetschen
- Victron CCGX (https://www.victronenergy.de/panel-systems-remote-monitoring/color-control), das bietet wohl - unter anderem - eine MQTT hotline, die ich aktiviert habe und auch mit mosquitto anzapfen kann
Rein intuitiv würde ich sagen, dass das Thermomenter vielleicht die einfachere Beute ist.
Im Idealfall würde ich also gerne gemäß https://wiki.fhem.de/wiki/Quick-Start#Daten_aufzeichnen_und_darstellen von dem Thermometer über SNMP Daten abgreifen und dann in FHEM anzeigen. Das THermometer hat zwar ein eigenes Webfrontend, aber für die Graphen verwenden die just Flash, was natürlich keiner mehr hernimmt.
Ich werde natürlich versuchen mich da durchzubeissen, aber wenn sich da jemand erbarmt und mich ein wenig an der Hand nimmt, wäre ich dankbar.
Oder - falls jemand meint die MQTT Kommunikation mit dem Victron wäre ein lohnenswertes Ziel, dann das, oder beides. ;-)
Und wenn es nicht out-of-the-box geht, kein Problem vielleicht purzelt dann auch mal Code meinerseits raus.
Hi,
ich denke MQTT ist von der Anbindung her "simpel":
Server
define mqtt2s MQTT2_SERVER 1883 global
etwas Sicherheit
define allowedMqtt allowed
attr allowedMqtt validFor mqtt2s
set allowedMqtt basicAuth username password
Dann schaust Du mal was MQTT2 draus macht :)
Gruß Otto
Ui Otto, du hast aber schon gesehen, dass das eventuell eine Art Interface für "alles mögliche" ist...?
@RichardCZ:
Trotzdem dürfte Otto am Ende recht behalten, wir können gerne versuchen, das auch gleich so aufzubereiten, dass es der nächste mit so einem Gerät gleich viel einfacher hat und sowas wie "best practice" dazu teilen kann...: attrTemplate.
Falls es sowas ist wie ein Interface, über das viele Geräte/Baugruppen reinkommen, wird es etwas komplizierter, und es wäre gut, du könntest etwas mehr an Infos zum MQTT-Verkehr liefern.
Helfe gerne, jetzt wäre erst mal etwas Info hilfreich (gerne auch ein Link mit etwas Info, "wie" das Teil MQTT spricht).
Beta-User
(einer der bekennenden Hobby- (oder besser eigentlich: Nicht-) Programmierer hier im Forum, der trotzdem irgendwie Maintainer "geworden" ist... Können wir gerne an anderer Stelle vertiefen ;) .).
Deswegen habe ich mich ganz vorsichtig ausgedrückt. ;) Die MQTT Anbindung ist erstmal simpel - aber wir müssen sehen was da reinkommt.
Am Ende ist SNMP vielleicht auch was simples, aber ich weiß nicht ob es ein Interface in FHEM dafür gibt. Deswegen hab ich dazu erstmal nix gesagt :)
Zitat von: Otto123 am 17 März 2020, 14:55:59
Am Ende ist SNMP vielleicht auch was simples, aber ich weiß nicht ob es ein Interface in FHEM dafür gibt.
IMHO nutzen "nur" zwei Module SNMP : 32_SYSSTAT und 73_PRESENCE, ein reines FHEM SNMP Modul gibt es nicht.
Das wäre aber vllt doch was für RichardCZ als Vorzeigemodul für uns Hobbyprogger, dann würde ich endlich mal lernen wie man es richtig macht (habe jetzt zwei Wochen viel Zeit) und könnte meinen Cisco Switch perfekt in FHEM einbinden :)
Erstmal bin ich noch beim Studieren. ;-)
Das bekomme ich vom Victron
# mosquitto_sub -v -I myclient -t '#' -h 192.168.2.219
N/847e40668538/system/0/Serial {"value": "847e40668538"}
ist ein wenig mager.
Das bekomme ich vom Thermometer:
$ snmpget -v1 -c public 192.168.2.156 .1.3.6.1.4.1.21796.4.1.3.1.5.1
SNMPv2-SMI::enterprises.21796.4.1.3.1.5.1 = INTEGER: 227
(22,7°C) - das stimmt soweit. Nebenher lese ich auch noch die vorzügliche Pflichtlektüre von Maaß/Pittner.
Ich habe ja dank COVID19 HomeOffice - da habe ich jetzt ein paar Tage um mich fortzubilden.
Den FHEM code habe ich ja mal nach SNMP durchsucht - irgendwas ist ja vorhanden. Ich muss da nur noch meinen Kopf drum "rumwickeln".
PRESENCE macht was mit SNMP - aha? ;)
Zitatdefine <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]
Checks for a presence state via perl-code. You can use a self-written perl function to obtain the presence state of a specific device (e.g. via SNMP check).
The function must return 0 (absent) or 1 (present). An example can be found in the FHEM-Wiki.
Example
define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")}
Nachgeschaut: ok - self-written 🤣 oder ist da noch was?
Ja aber wie der Name ja schon sagt SIMPLE Network ...
ZitatN/847e40668538/system/0/Serial {"value": "847e40668538"}
Na wird jetzt kein spannendes MQTT2 Device draus.
Hast Du ne Idee was das für ein Wert ist? Steht ja im Topic und im Wert das Gleiche :(
Zitat von: Otto123 am 17 März 2020, 19:44:27
Na wird jetzt kein spannendes MQTT2 Device draus.
Hast Du ne Idee was das für ein Wert ist? Steht ja im Topic und im Wert das Gleiche :(
Ich würde meinen, das ist die Seriennummer. Es sieht fast so aus, als ob Victron die Daten automatisch an mqtt.victronenergy.com sendet, sobald man MQTT anmacht. Vermutlich ist das "deren MQTT broker". Vielleicht bekommt man von dort mehr daten, aber so ganz steige ich da noch nicht durch.
Momentan konzentriere ich mich auf das SNMP Gerät. Was macht der Perl Hacker? Er schaut ob es nicht schon was gibt.
Also falls es noch keine "reinen SNMP" Module gibt in FHEM, dann schaue ich erstmal auf Metacpan, hole mir https://metacpan.org/pod/Net::SNMP (https://metacpan.org/pod/Net::SNMP) und https://metacpan.org/pod/SNMP (https://metacpan.org/pod/SNMP) und teste ob ich die Daten vom Thermometer mit einem Perl Skript dank dieser Module auch ausgelesen bekomme.
Wenn ja, sollte dann ein hübsches FHEM Modul folgen.
Hier steht was im OpenHAB-Forum zum Victron CCGX und MQTT:
https://community.openhab.org/t/mqtt-1-x-2-x-interface-to-victron-ccgx/43888
Man muß dem Teil wohl immer sagen, daß man auch zuhört.
Tadaaa
#!/usr/bin/env perl
use strict;
use warnings;
use v5.26.0;
use Net::SNMP;
my $OID = shift || '1.3.6.1.4.1.21796.4.1.3.1.5.1';
my $hostname = shift || 'localhost';
my ($session, $error) = Net::SNMP->session(
-hostname => $hostname,
-community => 'public',
);
if (!defined $session) {
say "ERROR: $error";
exit 1;
}
my $result = $session->get_request(-varbindlist => [ $OID ])
// do {
say 'ERROR: ', $session->error();
$session->close();
exit 1;
};
say 'The Temp for host ', $session->hostname(),
' is ', sprintf ("%.1f", $result->{$OID} / 10),
'°C';
$session->close();
exit 0;
entsprechend nach Aufruf dann:
$ snmp.pl 1.3.6.1.4.1.21796.4.1.3.1.5.1 192.168.2.156
The Temp for host 192.168.2.156 is 22.5°C
So. Jetzt muss ich nur schauen, wie ich das Net::SNMP API in FHEM reinknödle.
Man kann ja parallel an dem MQTT-Thema arbeiten...?
An dem MQTT2-Gerät hätte man auch die subscriptions gesehen, ganz so langweilig wäre es also nicht gewesen ;) .
So gäbe es schon mal was, dem man alle 50 Sekunden mit einem at einen Ping senden kann (unterstellt, es gibt ein MQTT2-IO (empfohlen immer noch: MQTT2_SERVER)):
attr DEVICE readingList N/847e40668538/system/0/Serial:.* { json2nameValue($EVENT, '', $JSONMAP) }
attr DEVICE setList update:noArg R/847e40668538/system/0/Serial
Vermutlich wäre es sinnvoll, dem ganzen eine bridgeRegexp zu verpassen, keine Ahnung, was da alles an Antwort kommt, aber dem OpenHAB-Thread nach könnte das uU. eine ganze Menge sein...
Zitat von: Wzut am 17 März 2020, 18:52:26
Das wäre aber vllt doch was für RichardCZ als Vorzeigemodul für uns Hobbyprogger, dann würde ich endlich mal lernen wie man es richtig macht (habe jetzt zwei Wochen viel Zeit) und könnte meinen Cisco Switch perfekt in FHEM einbinden :)
Tja ... Alter Schwede ... da muss ich aber erstmal den Urwald roden bevor ich da ein Häuschen hinsetzen kann. Gleichzeitig muss ich aber auch vorsichtig anfangen um nicht mehr kaputtzumachen als schon kaputt ist. Da wäre natürlich eine Testsuite nett gewesen.
Ich plane ein FHEM::SNMP zu machen, da muss ich aber erstmal dahintersteigen wie ich das aber in den vorhandenen Namespace-Brei richtig integriere.
Meine ersten beschwerlichen Schritte in der Richtung kann man ja in den commits in meinem Git Repo beobachten.
Startpunkte:
https://wiki.fhem.de/wiki/DevelopmentModuleIntro
https://wiki.fhem.de/wiki/DevelopmentModuleAPI
- Bitte externe Abhängigkeiten (use Net::SNMP;) vermeiden. (shall)
- 1x FHEM modul besteht aus 1x Datei, ist also self containing.
- Alle IO Operation müssen (must) asynchron implementiert werden. Dazu stehen eine IO loop (select) bereit.
FHEM ist eventbasiert, alle Module arbeiten im Rahmen von kooperativem Multitasking zusammen:
Stelle sicher dass das Modul auch bei externen Abweichungen wie Ausfall der Netzanbindung und/oder des DNS Servers nicht blockiert. (Net::SNMP implementiert die Abfrage synchron daher ist es generell nicht! geeignet)
Zitat von: herrmannj am 18 März 2020, 10:10:19
- Bitte externe Abhängigkeiten (use Net::SNMP;) vermeiden. (shall)
Das ist eine ziemlich dumme Regel. Ich weiß natürlich warum die da ist (um die Installationskomplexität gering zu halten)
natürlich werde ich mich bemühen nicht unnötig das halbe CPAN einzuschleusen, aber bevor ich so schlechte Räder neu erfinde wie offensichtlich bereits geschehen, werde ich diese shall-Regel doch arg biegen.
Zitat
Stelle sicher dass das Modul auch bei externen Abweichungen wie Ausfall der Netzanbindung und/oder des DNS Servers nicht blockiert. (Net::SNMP implementiert die Abfrage synchron daher ist es generell nicht! geeignet)
Das kommt daher, wenn man offensichtlich eine Aversion gegen CPAN entwickelt hat. Man liest gar nicht mehr die Doku zu den Modulen dort.
https://metacpan.org/pod/Net::SNMP#Non-blocking-Objects
Rest ist klar.
Sorry aber da höre ich etwas die "Arroganz" des professionellen Softwareentwicklers.
CPAN hört sich immer gut an, nur sind hier sind sehr viele Home-Administratoren unterwegs. Wenn die mal ein Betriebsystemupdate machen und dabei perl upgedatet wird, geht erstmal wenig ... da vergessen wird, CPAN upzudaten. Als Folge wird kein Update mehr gefahren ... DIE Problematik sollte bekannt sein.
Es ist also besser, wenn ein Modul mit gängigen Bibliotheken der gängigen Betriebsysteme geht .. und erst, wenn das nicht geht auf CPAN auszuweichen.
Im Profiumfeld kann und muß man damit umgehen, aber im Home-Administrationsumfeld ....
Ich sehe das Problem nicht. Es gibt ja einige Module, für die zusätzliche Perl-Module benötigt werden. Üblicherweise gibt man das z.B. in der commandref mit an, am besten mit Namen des entsprechenden Debian-Pakets, hier z.B. libnet-snmp-perl.
Zitat von: Wernieman am 18 März 2020, 11:13:38
Sorry aber da höre ich etwas die "Arroganz" des professionellen Softwareentwicklers.
Ja, das kann durchaus sein. Ist aber nicht der profi-Softwareentwickler, aber der INTJ. ;)
Zitat
CPAN hört sich immer gut an, nur sind hier sind sehr viele Home-Administratoren unterwegs. Wenn die mal ein Betriebsystemupdate machen und dabei perl upgedatet wird, geht erstmal wenig ... da vergessen wird, CPAN upzudaten. Als Folge wird kein Update mehr gefahren ... DIE Problematik sollte bekannt sein.
Klar. Da könnte man dann ja jemanden fragen, der sich damit auskennt. carton, perlbrew,...
Endziel sollte eigentlich sein, dass ein HomeAdmin im Webfrontend auf "update" klickt oder "update" in der Kommandozeile eingibt, dann wartet man eine Weile und dann ist ein neues FHEM da.
Rolling release. Da arbeite ich darauf zu.
Zitat
Es ist also besser, wenn ein Modul mit gängigen Bibliotheken der gängigen Betriebsysteme geht .. und erst, wenn das nicht geht auf CPAN auszuweichen.
Nö - siehe oben. Das Update geht noch wesentlich luxuriöser als jetzt
UND mit der geballten CPAN Power.
Man muss nur wissen wie und wollen.
Leute, die "euch" dabei helfen können dieses Ziel zu erreichen der "subjektiv empfundenen Arroganz" zu bezichtigen ist jetzt meiner Ansicht nach nicht so der Königsweg, aber jedem das Seine.
Tja .. FHEM Update <> Betriebsystem Update ...
Zitat von: Wernieman am 18 März 2020, 11:38:16
Tja .. FHEM Update <> Betriebsystem Update ...
Tja. perlbrew. Vielleicht erstmal die Begriffe nachschauen die ich so hinwerfe.
Edith:
Ok, ok, ... damit ich auch konkrete Infos gebe:
https://perlbrew.pl/
siehe "What is perlbrew", das Wichtigste in Kürze:
Zitatperlbrew is a tool to manage multiple perl installations in your $HOME directory. They are completely isolated perl universes. This approach has many benefits:
- No need to run sudo to install CPAN modules, any more.
...
- Test your production code against different perl versions. (Anm.: Für Entwickler)
- Leave vendor perl (the one that comes with OS) alone
Vendor perl usually serves its own purposes, and it might be a bad idea to mess it up too much. - Especially PITA when trying to upgrade system perl.
- Some vendors introduced their own perl bugs, twice!
Mit anderen Worten: Damit entkoppelt man die Perl Installation vom OS, gibt sie unter die Verfügungsgewalt des Users (bzw. des Prozesses, der mit User-Rechten läuft)
Mein FHEM läuft unter Perlbrew (5.30)
Zitat von: mahowi am 18 März 2020, 11:25:02
Ich sehe das Problem nicht. Es gibt ja einige Module, für die zusätzliche Perl-Module benötigt werden. Üblicherweise gibt man das z.B. in der commandref mit an, am besten mit Namen des entsprechenden Debian-Pakets, hier z.B. libnet-snmp-perl.
FHEM läuft auf vielen unterschiedlichen Systemen, darunter "Exoten" auf denen weder perlbrew noch CPAN zur Verfügung steht. Mit "libnet-snmp-perl" kann noch nicht einmal der Windows Anwender etwas anfangen. Deswegen auch "shall".
Die Verwendung von externen Abhängigkeiten schließt Benutzer aus oder verschlechtert die Benutzer Erfahrung. Das gilt zum Beispiel für ein FHEM Update. Das wird von einem Client aus via Browser angestoßen. Wenn jetzt CPAN Module erforderlich werden muss der Benutzer sich mit dem OS des Servers verbinden. Darüber dass dann nicht jeden CPAN xxx auch gleich problemlos funktioniert muss ich doch mit einem Profi nicht reden. Oder ;) ?
Zitataber bevor ich so schlechte Räder neu erfinde wie offensichtlich bereits geschehen, werde ich diese shall-Regel doch arg biegen.
Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.
Liefere Dein erstes Modul und beweise dass Du das auf Dauer und für verschiedene Systeme supporten kannst und möchtest.
Zitat von: herrmannj am 18 März 2020, 12:04:59
Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.
Ignorant. Damit ist die Diskussion für mich beendet. Dass es gute Implementierungen gibt habe ich nicht bestritten, ich habe nur gesagt, dass es einige gibt, die ziemlich scheisse sind. Namen muss ich jetzt keine nennen, könnte aber.
Zitat
Liefere Dein erstes Modul und beweise dass Du das auf Dauer und für verschiedene Systeme supporten kannst und möchtest.
Kann ich nicht, will ich nicht. Kann definitiv nicht Windows supporten, da 0 Erfahrung mit dem OS.
Zitat von: herrmannj am 18 März 2020, 12:04:59
FHEM läuft auf vielen unterschiedlichen Systemen, darunter "Exoten" auf denen weder perlbrew noch CPAN zur Verfügung steht. Mit "libnet-snmp-perl" kann noch nicht einmal der Windows Anwender etwas anfangen. Deswegen auch "shall".
Die Verwendung von externen Abhängigkeiten schließt Benutzer aus oder verschlechtert die Benutzer Erfahrung. Das gilt zum Beispiel für ein FHEM Update. Das wird von einem Client aus via Browser angestoßen. Wenn jetzt CPAN Module erforderlich werden muss der Benutzer sich mit dem OS des Servers verbinden. Darüber dass dann nicht jeden CPAN xxx auch gleich problemlos funktioniert muss ich doch mit einem Profi nicht reden. Oder ;) ?Unsinn, Blödsinn und Arrogant, FHEM enthält unter anderen MQTT, Comet und Websocket Cleanroom Implementierungen die sehr gut sind.
Dafür gibt's aber auch seit einiger Zeit das Modul Installer (https://fhem.de/commandref.html#Installer):
ZitatInstaller - Module to update FHEM, install 3rd-party FHEM modules and manage system prerequisites
ZitatKann ich nicht, will ich nicht. Kann definitiv nicht Windows supporten, da 0 Erfahrung mit dem OS.
Dann hör auf zu quengeln und streng Dich mehr an :) Mac OS, Einplatinen- und SOC Systeme gehören genauso wie unterschiedliche Perl Version zum Soll.
@herrmannj, als guter Wille ja - aber mal Hand aufs Herz : welcher Modulautor hat wirklich den kompletten Hardware Zoo zum testen ?
Ich kann die Tests meiner Module auch nur auf Raspian und Ubuntu beschränken, dh. laut FHEM Stats sollte das für über 5000 Installationen dann passen (vs, 46 Win/MAC User)
Ich schrieb auch nicht MUSS sondern SOLL und es geht auch nicht ums testen sondern darum dass beim coden zu berücksichtigen.
Wenn ich eben das Vorhandensein von perlbrew und CPAN (zieht einen compiler und wechselnde weitere libs pro modul nach sich) voraussetze oder syscalls verwende die systemspezifisch sind, dann schränke ich den Nutzer von vornherein ein.
Ein perl ist fast überall verfügbar und ein {print 'Hello world'} läuft auf dem mainframe und auf der Armbanduhr (da bin ich mir sicher obwohl ich beides nicht besitze:)). Dass es Gründe geben kann auf externe Abhängigkeiten zurückzugreifen liegt auf der Hand. Die Frage die man sich stellen soll lautet "ginge es auch ohne".
achtung: Net::SNMP ist blockierend und auch sonst nicht besonders schnell. ohne ein wenig 'drum rum' um es mit BlockingCall oder CoProcess oder was auch immer besser fhem tauglich zu machen. es kommt damit im normalen betrieb und abhängig von der gegenseite bis zu mehreren sekunden blockierung von fhem. es ist es nicht optimal um für den einstieg ein neues modul zu entwickeln.
die aktuelle verwendung in SYSSTAT ist eine 'jugendsünde', die neue version die leider nich nicht eingecheckt ist macht das mit einigen klimmzügen nicht blockierend und behindert fhem nicht mehr.
es gibt noch weitere probleme mit cpan modulen die man im auge behalten muss: nicht oder schwierig in die fhem mainloop integrierbar, das überschreiben von standart perl routinen, sich beenden im fehlerfall, ...
abgesehen davon: cpan module zu nutzen finde ich nicht schlimm. so lange man nicht mit ein klein wenig mehr aufwand eine besser integrierte lösung bauen kann, das ganze nicht wie wild nutzt ohne sich gedanken zu machen und sich idealer weise ausser für spezielle dinge auf eine kleine anzahl zentraler module beschränkt.
aber ein modul muss dann:
- drauf hinweisen das ein externes modul für eine bestimmte funktionalität nötig ist
- damit klar kommen wenn das externe modul nicht da ist, zumindest fhem nicht lahm legen
- den anwender drauf hinweisen
- ...
ps: mac ist normalerweise unproblematisch, das geht eigentlich einfach. windows sehe zumindest ich als völlig optional an :) und ist gerade bei den oben angesprochenen non-blocking geschichten tatsächlich speziell.
Hallo
Nur zur Info
Das ist auch ein "Modul" das über snmp spricht:
https://wiki.fhem.de/wiki/TCW120 (https://wiki.fhem.de/wiki/TCW120)