Raspberry WLan Steckdosen ?

Begonnen von MalcomX, 22 Januar 2019, 21:05:14

Vorheriges Thema - Nächstes Thema

MalcomX

Hallo erst mal  :)

Ich möchte mich mal bisschen in die ganze Thematik einarbeiten und habe mir vor kurzem ein so ein WLAN Steckdosenset gekauft von Smartwares ....

Hier entlang

Kann ich diese Steckdosen überhaupt alleine mit Bordmitteln (WLan) vom Raspberry ansteuern ?

Nun möchte ich diese mit einem Raspberry verbinden und vorerst mal darüber schalten .... Anfangs grad für mich bissi verwirren was wofür genutzt wird ....

Node Red schon paar Videos gesehen nur blick ich nich so ganz wie die Anbindung der Steckdosen funktioniert ..... FHEM ..... MQTT ? Fragen über Fragen :-D

Nur um mal die Funktionsweise zu verstehen, was für was zuständig ist .....

Verstehe ich das richtig, das FHEM oder MQTT die Schnittstelle zu meinen Steckdosen bereitstellt für Node Red ?

Gruß und Danke schon mal im voraus für eure Infos
Malcom

Beta-User

Zitat von: MalcomX am 22 Januar 2019, 21:05:14
Fragen über Fragen :-D
Das trifft es gut...

Die Anfängerdoku hast du durchgearbeitet? Wenn nein: besser da anfangen (mind. den QuickStart im Wiki).

Die Dinger sind m.E. deswegen so verwirrend, weil die eine Art Basisstation haben. So wie du das schreibst, kann die MQTT. Dann solltest du wissen, dass es drei Varianten gibt, wie man mit MQTT-Geräten "spricht": https://wiki.fhem.de/wiki/MQTT.

Hier würde ich annehmen, dass du schon einen Broker am laufen hast. Dann am besten MQTT2_CLIENT verwenden, den auf autocreate stellen und auf das erste MQTT2_DEVICE-Gerät, das erstellt wird (müßte erfolgen, wenn du irgendwas da schaltest), auf das dann das template A_00_MQTT2_CLIENT_general_bridge anwenden. Dann nochmal schalten, es sollte wieder ein Device per autocreate erstellt werden.

Infos zu attrTemplate usw. findest du hier: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#Einf.C3.BChrung:_MQTT_bzw._MQTT2_in_FHEM

Wichtig: Dein FHEM sollte unbedingt aktuell (=heutiges update!) sein!

Wenn du das geschafft hast, wieder melden...

Gruß, Beta-User
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

gloob

#2
Deine Steckdosen die du gekauft hast laufen nicht mit WLAN, sondern mit 433MHz. Die könntest du mit Glück mit einem nanoCUL/MapleCUL/Signalduino in FHEM bekommen.
Ob du die "Basisstation" mit MQTT steuern kannst, solltest du in der Smartwares App herausfinden können.

Sorry wenn ich das so sage, aber meinen Meinung nach sind die Steckdosen Schrott.
Kauf dir welche von Gosund oder der gleiche und flashe die Tasmota Firmware. Dann kannst du sie über Alexa oder MQTT steuern, ohne dass du ein eigenes Gateway wie bei deinen Smartwares brauchst.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

Zitat von: gloob am 23 Januar 2019, 09:13:51
Sorry wenn ich das so sage, aber meinen Meinung nach sind die Steckdosen Schrott.
Stimme da voll zu...
ZitatKauf dir welche von Gosund oder der gleiche und flashe die Tasmota Firmware. Dann kannst du sie über Alexa oder MQTT steuern, ohne dass du ein eigenes Gateway wie bei deinen Smartwares brauchst.
Das sehe ich anders:
1. durch das Flashen können versicherungsrechtliuche Probleme entstehen. Also nimmt man besser was, was ohne firmware-Mod läuft (evtl. Shelly)

2. (nur meine 2ct!) WLAN ist sowieso was, was in der Hausautomation allenfalls in Randbereichen was verloren hat (oder besonderer Rahmenbedingungen bedarf, die der Heimandwender in der Regel nicht erfüllt!). Ok für den Einstieg, kann man erst mal ein wenig mit rumspielen... Aber alles, was wirklich wichtig ist, sollte man auf anderem Weg steuern. Also: Kauf dir mittelfristig "was richtiges" mit einem für HA geeigneten bidirektionalen Funkstandard wie Zwave.
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

Pfriemler

Ich bin dem "Hier entlang" gefolgt und entdecke dort ein Set von Steckdosen, die über eine Fernbedienung (433 MHz) und über WLAN (2,4 GHz - beide Frequenzen stehen in den Spec), vermutlich über die omnipräsente Tuya-Cloud, gesteuert werden können. Aber ich sehe kein Gateway und lese nix von MQTT.
Zwei Funkstandards kennt man von Sonoff ja auch.

[ironie]
Schrott ist das genauso wie die berühmten Baumarktsets, alle gosunds, Blitzwolf, Obi & Co. Richtig gut kann nur sein, was richtig Geld kostet.
Und wer sich dem Risiko aussetzt und das bewährte Tasmota auf die beliebten Sonoffs zieht, die weltweit von einer riesigen Community (von der 98% noch nie von FHEM gehört haben werden) eingesetzt werden und bei denen es regelmäßig zu Bränden infolge eigengeflashter Firmware kommt, der braucht sich nicht wundern, wenn er den nächsten Winter unter der Brücke verbringt.
[/ironie]

Über das tatsächlich erhöhte Risiko durch den Einsatz eigenmächtiger Firmware sollte vielleicht mal diskutiert werden. Aber nicht hier.
Nichtsdestotrotz ist die Empfehlung, von vornherein auf eine bastelfreie Lösung zu setzen, nicht dick genug zu unterstreichen besonders für jene, die kein nicht zu unterschätzendes Mindestmaß an Kenntnis und gesunder Ehrfurcht vor der Technik besitzen.

Und ja, WLAN ist nicht sinnvoll für Dinge von Wichtigkeit. Aber es ist manipulationssicherer als Homematic ohne AES und vor allem die Baumarktböller.

Jm2c
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Wernieman

ZitatRichtig gut kann nur sein, was richtig Geld kostet.
Sorry, aber ... damit behauptest Du im Umkehrschluß:
1. Damit behauptest Du im Umkehrschluß: Gut ist, was teuer ist .... meinst Du das ernsthaft? Habe schon genug teuren Schrott gesehen
2. Damit komme ich zu: Quallität hat NICHTS mit dem Preis zu tuehn. Es gibt billigen und teuren Schrott .. genauso wie billige und teure Quallität
3. Nicht mal auf Marke knn man sich verlassen ....

Btw:
Man sollte auch vorsichtig sein, mit "Masse" zu argumentieren. Wenn Jetzt von 10.000 Usern eine Steckdose Abfackelt, steht es im Netz. Wenn jetzt aber nur 100 es gekauft haben und 1. brennt, wirst Du es nicht finden ... auch wenn sie viel schlechter ist.

Kurz gesagt:
Vorsicht mit Pauschalen Aussagen!

Sonst kauft man zu teuer (und zu schlecht)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Pfriemler

Du hast meine Ironie-Tags ignoriert ...  ;)

Ich kenne auch teuren Schrott und preiswerte erstaunlich solide gebaute Geräte. Gerade die Schaltsteckdosen haben eine erstaunliche Bandbreite. Man kann es eben nicht pauschal sagen. Und von den schlechten Geräten geht auch im Originalzustand eine erhöhte Gefahr aus, die sich m.M.n. durch den Einsatz anderer Firmware nicht wirklich ändert.

Und Masse hilft schon: Hätten die Sonoffs ein Problem mit der Sicherheit,  dann wüssten wir es. Deswegen greife ich auch lieber auf Bewährtes zurück, auch wenn es einmalig etwas mehr kostet.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Zitat von: Pfriemler am 24 Januar 2019, 11:52:02
Und Masse hilft schon: Hätten die Sonoffs ein Problem mit der Sicherheit,  dann wüssten wir es. Deswegen greife ich auch lieber auf Bewährtes zurück, auch wenn es einmalig etwas mehr kostet.
:) Wenn ich daran erinnern darf: Es gab mit einer Charge Sonoffs mal ein Problem, oder habe ich das falsch im Kopf?

Zitat von: Pfriemler am 24 Januar 2019, 11:52:02
Ich kenne auch teuren Schrott und preiswerte erstaunlich solide gebaute Geräte.
+1 (man denke an dieses Kondensatorenthema einer deutschen Firma...)
ZitatGerade die Schaltsteckdosen haben eine erstaunliche Bandbreite. Man kann es eben nicht pauschal sagen. Und von den schlechten Geräten geht auch im Originalzustand eine erhöhte Gefahr aus, die sich m.M.n. durch den Einsatz anderer Firmware nicht wirklich ändert.
Auch richtig: Schlechtes elektisches Design bleibt schlechtes Design, egal, welche firmware man drüberhaut.
Es ging mir auch nicht drum, tasmota schlechtzureden oder das flashen irgendwelcher firmwares zu verteufeln. Aber wie belesenere Leute ich ich an anderer Stelle zu den shellys schon angemerkt haben: Es ist eben nicht mehr das Gerät wie vom Hersteller geliefert. Wenn etwas schiefgeht, sucht erfahrungsgemäß jeder potentielle Anspruchsgegner jeden Strohhalm, um von einer eventuellen Haftung wegzukommen. That's all.
Deswegen finde ich die schnelle Analyse "Ist ein ESP8266 => so schnell wie geht, andere firmware drauf, dann ist alles gut" halt einfach etwas kurz gegriffen.

Also: Eine umfassende (-re) Recherche (als sie der TE hier gemacht hat), kann bestimmte Risiken vermindern, aber nicht komplett vermeiden.

Und ansonsten sollte man halt _vorher_ überlegen, was man sich auf welchem Weg "reinzieht". (Das Problem ist nur, dass man am Anfang bestenfalls eine ahnung von einer Ahnung hat, was alles wie reinspielen kann...).

Dass man den vollständigen Meinungsstand zu den vielfälitigen Aspekten nicht immer vollständig in eine erste Antwort reinbekommt, ist schade, aber leider menschlich.
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

Pfriemler

Ich nutze selbst keine Sonoff. Könnte sein dass da mal was war. Aber ich würde mich in jedem Fall einlesen, wenn ich vorhabe etwas neues einzusetzen.
Zitat von: Beta-User am 24 Januar 2019, 12:05:08
... man denke an dieses Kondensatorenthema einer deutschen Firma...
Welches wenigstens nicht sicherheitsrelevant ist. Aber schrottig. Und mit einer Reparatur mit einem passenderen Ersatzteil bewegen wir uns auf größeres Glatteis, strohhalmtechnisch gesprochen: Ich möchte den Gutachter sehen, der eine abgebrannte Schaltsteckdose auf die verwendete Firmware untersucht, besonders wenn sie auf diese ent-Tuya-Cloud-ete Variante aufgespielt wurde - ganz ohne Hardwaremod am Gerät.

Es ist ja leider mordern, sich aus jeder Verantwortung zu stehlen, siehe auch Verweigerung von Hardwarereparaturen bei alternativen ROMs bei Handys. Was hat ein Rooten des Handys mit der mechanischen Stabilität der USB-Buchse zu tun? Richtig, nichts.

Just aus diesem Grund sind die Shellys in der Tat eine echte Alternative. Ich werde mal meine Einkaufspolitik überdenken...

Im Wohnzimmer setze ich übrigens nächstens einen Eigenbau als Netzschalter für alle Mediengeräte ein: 8er Relaiskarte, angesteuert über ein Homematic-Modul, gespeist von einem externen (und damit gut belüfteten) Handynetzteil. Luft- und Kriechstrecken allesamt > 1cm auf der Platine, sonst viel größer, saubere Trennung von Netz- und Kleinspannungsseite... Meine Koukaam NETIO230B sieht innen gefährlich dagegen aus.  ;) Ach ja: Standby unterhalb der Messgrenze (<0,1 W). Als ob es so schwer wäre ...


"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Zitat von: Pfriemler am 24 Januar 2019, 12:59:36
Ich möchte den Gutachter sehen, der eine abgebrannte Schaltsteckdose auf die verwendete Firmware untersucht, besonders wenn sie auf diese ent-Tuya-Cloud-ete Variante aufgespielt wurde - ganz ohne Hardwaremod am Gerät.
Wäre doch eine Geschäftsidee: Über die Einbindung der früher mal vorhandenen Geräte in irgendeine beliebige HA-Lösung feststellen, ob die firmware manipuliert wurde... Dafür braucht man kein verkohltes Silizium zu reanimieren ;) . Nur etwas Coding betrachten oder schlichte Recherchearbeiten in einem Forum deiner Wahl...
Kommt auf die Schadenssumme an, aber das könnte sich (für die Versicherung/die Fa., eher nicht für den Betroffenen) lohnen :P .

Zum Rest: War nicht als Werbung für bestimmte Produkte gemeint, auch da gab es (ebenfalls zwischenzeitlich behobene!) elektrische Probleme. (Das mit der Gewährleistung für Handys ist auch echter Mist, nutze auch am liebsten lineageOS! Ohne gaaps...). Und als Anfänger/Laie sollte man auch nicht versuchen, supersichere Lösungen nachzubauen, Strom ist immer noch potentiell tödlich ;) .

Aber wir schweifen ab, es bleibt dabei: keine Lösung ist vermutlich perfekt und keine Lösung ist auch keine Lösung. Also: Augen auf, möglichst vor dem Einkauf...

An den TE: Gibt es jetzt also eine Brücke irgendwo auf dem Teil in die MQTT-Welt oder hast du das verworfen? (dann bitte [gelöst])
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

Prof. Dr. Peter Henning

ZitatAugen auf, möglichst vor dem Einkauf
Amen, Bruder, Amen.

Es ist nichts so übel wie der Post "Ich habe da gerade mal billige Hardware gekauft, wie binde ich die jetzt in FHEM ein". Oder: "Wer schreibt mir ein Modul"...

LG

pah

Beta-User

Zitat von: Prof. Dr. Peter Henning am 24 Januar 2019, 15:58:29
Es ist nichts so übel wie der Post "Ich habe da gerade mal billige Hardware gekauft, wie binde ich die jetzt in FHEM ein". Oder: "Wer schreibt mir ein Modul"...
Ich hätte noch einen für die Liste:
Zitat von: MalcomX am 22 Januar 2019, 21:05:14
[...] schon paar Videos gesehen [...]

(Btw.: vorhin bin ich zufällig über ein Video eines bekannten, aber aus dem Forum geflohenen Videobloggers gestolpert (Erscheinungsdatum 8/2018). Jetzt weiß ich auch, warum hier grade so viele unbedarft aus irgendwelchen Quellen einen CUL anschleppen und dann merken, dass das nur die zweitbeste Lösung für HM ist (und nicht mal der Preisabstand die Wahl des CUL rechtfertigt). Niemand weiß alles, aber das fand ich dann doch mal wieder unterirdisch... Hat er keinen Lötkolben, um dem Pi- Modul einen USB-Wandler für seinen NUC zu spendieren? Oder gibt das keine so ansehlichen Videobilder?!?)

Amen!
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

pc1246

Moin
Ich bin auch mal dem link gefolgt. Da sehe ich dick und fett das "A...a"-Logo prangen. Das wurde doch gerade von Justme und einem weiteren fleissigen Helfer generisch gemacht. So koennte man auch starten, wobei das Lesen der einschlaegigen Dokumente davon unberuehrt bleibt!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

Wernieman

Mhhh .. "Links zum Video gefolgt" .. wo hast Du den denn hier gefunden?

Will mich auch mal "aufregen" ,o)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

[Sorry für OT]
@Wernieman
Von links zu einem Video stand nirgends was, nur von einem Link zu dem Set mit den Steckdosen (war im ersten Beitrag).

Nur wg. des show-me auch der link zum Video:
https://www.youtube.com/watch?v=Kyd97iFTH3U

Damit sollten wir das Thema auch beerdigen, auch wenn es mich wirklich ärgert, dass diese halbgaren Geschichten offenbar wichtiger sind wie unser Wiki...

(Vielleicht zum Hintergrund: Über das Video bin ich wirklich zufällig gestolpert, bei der Suche nach Infos zur Verwendung von Temperaturlisten für HM-Thermostate (die beste Quelle ist mal wieder das Wiki, btw). Das bezeichnete Video war jedenfalls unter den ersten Paar Treffern (aber natürlich für die eigentliche Frage völlig irrelevant)...

Mein UI hübsche ich grade etwas auf, habe aber keine Böcke auf irgendwas anderes als FHEMWEB; mehr als saubere Räume, Gruppen und DeviceOverviews in f18 braucht ja eigentlich auch keiner... (Leider erst) neulich bin ich darüber gestolpert, wie mächtig devStateIcon eigentlich ist, wenn man da Perl-Code reinschreibt :) . Allerdings sind "manche" HM-Devices zickig, weil man z.B. für die Thermostate Infos aus mehreren Kanälen zusammensuchen muß und sich die Teile eigentlich nur über den Climate-Kanal steuern lassen. Dabei bin ich wieder über die temp-Listen gefallen, die ich zwar nutze, aber bisher nicht im UI angeboten hatte; das wird übrigens auch im wesentlichen so bleiben, die attr-Lösung gefällt mir nicht so...)
[/OT]
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