Guten Abend,
ich versuche meinen sonoff-Basic in FHEM einzubinden, FHEM funktioniert so weit auch als "Server" aber der Basic hat ein Problem.
Ich möchte dem Device ein Template zuweisen, weiß aber nicht, was ich dann bei CMNDTOPIC, TELETOPIC, STATTOPIC eintragen muss.
Ich gebe euch gern weitere Infos, damit ihr mir helfen könnt.
Würde mich freuen. Vielen Dank und einen schönen Abend
Wenn du ein list (oder noch besser, einen RAW-Definition-Auszug) lieferst, wird es evtl. klarer (und ich kann nachschauen, warum es ggf. schief geht).
Grundsätzlich gehört da hin, was als Topic-Pfad jeweils konkret paßt (und es sollte automatisch - also ohne Dialogfeld - erkannt werden, wenn eine LWT-Message eingegangen war). Wenn das template "kaputt" ist, sollte ich noch wissen, welches.
wie kann ich die RAW-Daten oder das list ausführen, im set steht nur attrTemplate und dann halt die Auswahl, dieses auszuwählen.
get habe ich gar nicht
Ich gehe davon aus, dass du den angepinnten Beitrag zu "Was beachten vor Fragen?" kennst? Da steht was zu list...
Zu RAW: https://wiki.fhem.de/wiki/Raw_definition
Ich bräuchte das Device, auf das du das template anwenden willst...
defmod MQTT2_LampeSchlafzimmer MQTT2_DEVICE LampeSchlafzimmer
attr MQTT2_LampeSchlafzimmer IODev MQTT2_FHEM_Server
attr MQTT2_LampeSchlafzimmer autocreate 0
attr MQTT2_LampeSchlafzimmer model A_01a_tasmota_basic_state_power1
attr MQTT2_LampeSchlafzimmer readingList TELETOPIC/LWT:.* LWT\
TELETOPIC/STATE:.* { json2nameValue($EVENT) }\
TELETOPIC/SENSOR:.* { json2nameValue($EVENT) }\
TELETOPIC/INFO.:.* { json2nameValue($EVENT) }\
STATTOPIC/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_LampeSchlafzimmer room MQTT2_DEVICE
attr MQTT2_LampeSchlafzimmer setStateList on off toggle
attr MQTT2_LampeSchlafzimmer stateFormat POWER1
attr MQTT2_LampeSchlafzimmer webCmd ON:OFF
setstate MQTT2_LampeSchlafzimmer off
Hmmm, kannst du die readingList nochmal löschen und den tasmota zum Neustart überreden?
Ich benötige bitte das RAW nochmal mit der automatisch erstellten readingList vor dem Anwenden des templates (es sollte ein LWT-Reading da sein, sonst klappt das nicht mit der Analyse des Topic-Pfades...).
Und bitte künftig Code-Tags verwenden (der "#"-Button oberhalb der smileys).
Danke schon mal für die Mühen, habe es direkt in Code-Tag geändert, und hier der neue Auszug:
defmod MQTT2_LampeSchlafzimmer MQTT2_DEVICE LampeSchlafzimmer
attr MQTT2_LampeSchlafzimmer IODev MQTT2_FHEM_Server
attr MQTT2_LampeSchlafzimmer readingList LampeSchlafzimmer:tele/LampeSchlafzimmer/LWT:.* LWT\
LampeSchlafzimmer:cmnd/LampeSchlafzimmer/POWER:.* POWER\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO1:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO2:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:tele/LampeSchlafzimmer/INFO3:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:stat/LampeSchlafzimmer/RESULT:.* { json2nameValue($EVENT) }\
LampeSchlafzimmer:stat/LampeSchlafzimmer/POWER1:.* POWER1\
LampeSchlafzimmer:tele/LampeSchlafzimmer/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_LampeSchlafzimmer room MQTT2_DEVICE
defmod FileLog_MQTT2_LampeSchlafzimmer FileLog ./log/MQTT2_LampeSchlafzimmer-%Y-%m-%d.log MQTT2_LampeSchlafzimmer
attr FileLog_MQTT2_LampeSchlafzimmer logtype text
attr FileLog_MQTT2_LampeSchlafzimmer room MQTT2_DEVICE
setstate FileLog_MQTT2_LampeSchlafzimmer active
setstate FileLog_MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 linesInTheFile 26
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 FallbackTopic cmnd/LampeSchlafzimmer_fb/
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 GroupTopic sonoffs
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Heap 15
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Hostname LampeSchlafzimmer-1307
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 IPAddress 192.168.24.2
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:35 LWT Online
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 LoadAvg 19
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Module Sonoff Basic
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 POWER
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 POWER1 off
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 RestartReason Software/System restart
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Sleep 50
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 SleepMode Dynamic
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Time 2019-08-02T14:00:43
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Uptime 0T00:00:16
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 Version 6.6.0(release-sonoff)
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:36 WebServerMode Admin
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_AP 1
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_BSSId 7C:FF:4D:7F:3C:F9
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_Channel 10
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_Downtime 0T00:00:06
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_LinkCount 1
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_RSSI 56
setstate MQTT2_LampeSchlafzimmer 2019-08-02 15:00:44 Wifi_SSId XXXXXX
:)
Versuch's jetzt nochmal mit dem template. Jedenfalls mit der aktuellen Version aus dem regulären update konnte ich keine Probleme feststellen, und die ist eigentlich seit längerem unverändert.
Kann sein, dass das LWT-Reading bei dem ersten Versuch noch nicht da war. Dann hätte eigentich in die Dialogfelder der entsprechende Input reingehört, statt einfach das vorhandene zu bestätigen (die Dialogfelder fragen Variablen ab, wenn sie sie selbst nicht bestimmen können...).
PERFEKT! Ich danke von Herzen :-) vielleicht werde ich mir nun doch ein paar Tasmota zulegen ;)
Bester Support ever!! Schönes Wochenende
Danke für die nette Rückmeldung.
Zitat von: oehi86 am 02 August 2019, 15:53:52
vielleicht werde ich mir nun doch ein paar Tasmota zulegen ;)
Das würde ich mir nochmal überlegen... Ich supporte das mit den atttrTemplates für MQTT2_DEVICE zwar, aber das vertreibt nicht meie grundsätzliche Skepsis gegenüber dem "WLAN-Gedöns".
(Ich habe z.B. selbst neulich lieber einige ZWave-Aktoren verbaut statt Shelly oder Tasmota-Zeug, und wenn ich löte, nehme ich typischerweise MySensors (am liebsten @RS485), und keine ESP's.)
Ansonsten: Bitte als [gelöst] markieren... (Siehe angepinnten Thread im Anfängerbereich, wie das geht).
Auch wenn ich damit vollkommen OT bin und dieser Beitrag bereits als gelöst klingt und ich bei der Suche nach meinem Fehler hier drüber gestolpert bin, habe ich doch eine sehr dringende Frage:
Zitat von: Beta-User am 02 August 2019, 16:08:58
Danke für die nette Rückmeldung.Das würde ich mir nochmal überlegen... Ich supporte das mit den atttrTemplates für MQTT2_DEVICE zwar, aber das vertreibt nicht meie grundsätzliche Skepsis gegenüber dem "WLAN-Gedöns".
Du bist ja nun schon "ein wenig" erfahrener, was die ganze Geschichte angeht.... Woher kommt Deine Skepsis, bzw. warum bist Du dem "Wlan Gedöns" so abgeneigt ?
(Falls zu sehr OT auch sehr gern per PN)
Viele neugierige Grüße
Andreas
...lange Geschichte:
Also:
- Den ersten ESP8266 hatte ich in der Hand, als das framework noch nicht ausgereift war und sämtliche Mängel im Hardwaredesign noch besser sichtbar waren. Ich habe daraus für mich den Schluß gezogen, dass das allg. ein verräterisches Stück Hardware ist, und das Versprechen einer "eierlegenden Wollmilchsau" nicht zu halten. (Das ist besser geworden, aber das Mißtrauen gegen die Hardware ist weiter da...).
- Es ist WLAN. Damit das funktioniert mit der Datenübertragung, braucht man ziemlich viel Infrastruktur, die läuft (AP, Router, Switches...). Es kann Konflikte mit Nachbarn geben (Kanalwahl, Bandbreite) usw. Das ist mit einem USB-Dongle am Server was anderes. Da braucht - von Ausnahmen abgesehen - im Prinzip nur der Server Strom und der entfernte Aktor/Sensor, dann läuft das. Und ich muß nicht x Devices mit neuen Zugangsdaten versehen, wenn ich mal was am WLAN drehe...
- Es gibt zwischenzeitlich auch alle 2-3 Wochen einen neuen Thread mit - in etwa - dieser Fragestellung: "Hilfe, ich erhalte plötzlich keine Rückmeldung mehr von meinen Sensoren / meine Aktoren lassen sich nicht mehr schalten / was ist hier los...?"
Hintergrund ist in der Regel: es sind zu viele WLAN-Geräte für den vorhandenen Router (FritzBox) vorhanden.
(- für Funk-/Gesundheitsskeptiker: Das WLAN-Gedöns ist meistens "immer auf Sendung" und nicht nur dann, wenn wirklich Information übertragen werden soll. Wer also sowas wichtig findet, hat ein weiteres Argument.)
Ansonsten: Es geht nichts über Kabel ;D . Das ist nur immer zu kurz, wenn man es einmal abgeschnitten hat, aber ansonsten der dauerhafteste und zuverlässigste Weg, Daten zu übertragen...
Hallo Beta,
vielen lieben Dank für die ausführliche Antwort... Wenn es ok ist, würde ich gern drauf eingehen.
- Skepsis gegenüber der Hardware: Kann ich voll und ganz nachvollziehen. Da ich Elektriker bin, hab ich da auch so meine Bedenken gehabt und wenn ich überlege dass Leute da ihre Elektroheizung, Klima und ähnliches drüber laufen lassen, graut es mir. Da finde ich sparsame Kühlschränke oder Spülmaschinen die nur kurzfristig mal mehr als 4-5 A ziehen, schon grenzwertig.
- Eine gute Wlan Struktur ist natürlich unabdingbar, wenn man sowas vorhat. Da ist es in der Tat mir einer FritzBox nicht getan, da muss man schon etwas mehr für tun. (wäre das nicht vielleicht ein wichtiger Hinwes in der Wiki ?) Tatsächlich wird es ja so sein, dass die Leute immer mehr davon dazu nehmen (weil es ja so einfach ist und man eben keine andere Hardware braucht) und (so wie ich) skeptischer dem "normalen" Funk gegenüber sind.
- Natürlich sind die Funkwellen ein sehr sehr wichtiges Thema. Ich weiss das sprengt jetzt hier das Thema, aber wenn das Wlan für Handys und Mobile Geräte an ist, sendet es doch eh permanent. D.h. wenn ich aus Gesundheitsgründen auf Wlan Geräte in der Steuerung verzichten wollte, muss ich auch zwingend auf Wlan generell verzichten :o
Damit das ganze nochmal onTopic wird:
Ich hatte mal zwei Shellys für kleine Lampen in Betrieb genommen. Dort hat es gut funktioniert, dass ich nur den "Topic" namen genommen habe. Damit habe ich dann die beiden Templates: "A_01z_tasmota_set_lowercase_texts_and_state1" und "A_01z_tasmota_set_power1_state_to_power" zusätzlich dann das entsprechende Produkt ausgewählt.
Damit hatte ich den Vorteil, dass der state Zustand IMMER von POWER1 kommt und alles klein geschrieben ist also on statt ON und off statt OFF.
Jetzt habe ich das heute mal mit einem neuen Teil probiert und komme da richtig ins Schwitzen. Wenn ich ein anderes Device kopiere, die MQTT Adressen anpasse dann funktioniert es perfekt. Nehme ich aber ein nacktes Device und versuche dort die o.g. Einstellungen zu machen, scheitert es an den Angaben CMNDTOPIC, TELETOPIC, STATTOPIC. bzw irgendwas davon übernimmt er dann nicht.
Könntest Du so nett sein und ein Beispiel anhand des "RohDevices" unten geben, was man entsprechend eintragen muss wenn man nach den o.g. Sachen gefragt wird?
Internals:
CFGFN
CID Shelly9_SZ_E2059C
DEF Shelly9_SZ_E2059C
DEVICETOPIC MQTT2_Shelly9_SZ_E2059C
FUUID 5d8b3e02-f33f-8d79-502b-88b456be46e74678
IODev brok_MQTT2
LASTInputDev brok_MQTT2
MSGCNT 7
NAME MQTT2_Shelly9_SZ_E2059C
NR 24462
STATE ???
TYPE MQTT2_DEVICE
brok_MQTT2_MSGCNT 7
brok_MQTT2_TIME 2019-09-25 12:14:34
READINGS:
2019-09-25 12:14:33 FallbackTopic cmnd/Shelly9-SZ_E2059C_fb/
2019-09-25 12:14:33 GroupTopic sonoffs
2019-09-25 12:14:42 Heap 15
2019-09-25 12:14:33 Hostname Shelly9-SZ
2019-09-25 12:14:33 IPAddress 192.168.0.138
2019-09-25 12:14:33 LWT Online
2019-09-25 12:14:42 LoadAvg 19
2019-09-25 12:14:33 Module Shelly 1
2019-09-25 12:14:42 POWER OFF
2019-09-25 12:14:33 RestartReason Software/System restart
2019-09-25 12:14:42 Sleep 50
2019-09-25 12:14:42 SleepMode Dynamic
2019-09-25 12:14:42 Switch1 OFF
2019-09-25 12:14:42 Time 2019-09-25T12:14:42
2019-09-25 12:14:42 Uptime 0T00:00:13
2019-09-25 12:14:33 Version 6.6.0(release-sonoff)
2019-09-25 12:14:33 WebServerMode Admin
2019-09-25 12:14:42 Wifi_AP 1
2019-09-25 12:14:42 Wifi_BSSId B6:FB:E4:DA:35:78
2019-09-25 12:14:42 Wifi_Channel 6
2019-09-25 12:14:42 Wifi_Downtime 0T00:00:03
2019-09-25 12:14:42 Wifi_LinkCount 1
2019-09-25 12:14:42 Wifi_RSSI 98
2019-09-25 12:14:42 Wifi_SSId FlummyDevice
Attributes:
DbLogExclude .*
IODev brok_MQTT2
readingList Shelly9_SZ_E2059C:tele/Shelly9-SZ/LWT:.* LWT
Shelly9_SZ_E2059C:cmnd/Shelly9-SZ/POWER:.* POWER
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO1:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO2:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/INFO3:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/RESULT:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/POWER:.* POWER
Shelly9_SZ_E2059C:tele/Shelly9-SZ/STATE:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/SENSOR:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
Habs mal so probiert, wie ich es "kannte". Dann hat er zwar alles in Kleinbuchstaben gewandelt, aber ich kann vom MQTT Device nicht schalten, POWER1 reading gibt es nicht und toggle wird auch nicht angeboten. Also läuft da noch was falsch ;(
List vom "angepassten" Device
Internals:
CFGFN
CID Shelly9_SZ_E2059C
DEF Shelly9_SZ_E2059C
DEVICETOPIC MQTT2_Shelly9_SZ_E2059C
FUUID 5d8b3e02-f33f-8d79-502b-88b456be46e74678
IODev brok_MQTT2
LASTInputDev brok_MQTT2
MSGCNT 24
NAME MQTT2_Shelly9_SZ_E2059C
NR 24462
STATE off
TYPE MQTT2_DEVICE
brok_MQTT2_MSGCNT 24
brok_MQTT2_TIME 2019-09-25 12:20:10
OLDREADINGS:
READINGS:
2019-09-25 12:19:42 Heap 15
2019-09-25 12:19:42 LoadAvg 19
2019-09-25 12:20:10 POWER on
2019-09-25 12:19:42 Sleep 50
2019-09-25 12:19:42 SleepMode Dynamic
2019-09-25 12:19:42 Switch1 off
2019-09-25 12:19:42 Time 2019-09-25T12:19:42
2019-09-25 12:19:42 Uptime 0T00:05:13
2019-09-25 12:19:42 Wifi_AP 1
2019-09-25 12:19:42 Wifi_BSSId B6:FB:E4:DA:35:78
2019-09-25 12:19:42 Wifi_Channel 6
2019-09-25 12:19:42 Wifi_Downtime 0T00:00:03
2019-09-25 12:19:42 Wifi_LinkCount 1
2019-09-25 12:19:42 Wifi_RSSI 90
2019-09-25 12:19:42 Wifi_SSId FlummyDevice
2019-09-25 12:20:28 state off
Attributes:
DbLogExclude .*
IODev brok_MQTT2
model A_10_shelly1
readingList shellies/Shelly9-SZ/relay/0:.* state
shellies/Shelly9-SZ/relay/0:.* relay0
shellies/Shelly9-SZ/input/0:.* input0
shellies/Shelly9-SZ/online:.* online
shellies/Shelly9-SZ/announce:.* { json2nameValue($EVENT) }
shellies/announce:.* { $EVENT =~ m,..id...Shelly9-SZ...mac.*, ? json2nameValue($EVENT) : undef }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/STATE:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:tele/Shelly9-SZ/SENSOR:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/RESULT:.* { json2nameValue($EVENT) }
Shelly9_SZ_E2059C:stat/Shelly9-SZ/POWER:.* POWER
room MQTT2_DEVICE
setList off:noArg shellies/Shelly9-SZ/relay/0/command off
on:noArg shellies/Shelly9-SZ/relay/0/command on
x_update:noArg shellies/Shelly9-SZ/command update_fw
x_mqttcom shellies/Shelly9-SZ/command $EVTPART1
userReadings state:POWER:.* { lc(ReadingsVal($name,"POWER","")) }
Vielen Dank und viele Grüße
Andreas
Kein Ding, und vielleicht schreibt jemand auch irgendwann in's Wiki, dass WLAN so seine Haken hat ;D . Ich nutze das (fast) nicht und bin daher befangen/ahnungslos :P .
Was die Hardwareskepsis angeht: Gemeint war nicht nur das "drumrum" (auch wichtig, aber das kenne ich nicht), sondern vorrangig eigentlich den Espressif-IC. Schon der ist suboptimal, ich hatte damals erst mal nur ein paar mit 6 oder 8 nach außen geführten PINs (und das als Noob in dem ganzen Thema IC-Programmierung ::) )...
Was die shelly's angeht:
1. braucht man eigentlich für _Tasmota_-geflashte ESP's nicht die "Basistemplates" separat anwenden, das macht eigentlich das 1. in der Liste intern schon automatisch ;) .
2. Wie sind die geflasht? Noch original-firmware? Dann ist sowieso alles anders...
toggle sollten da die SetExtensions machen (könnte man in den templates ergänzen, wenn die das verstehen), und eigentlich dachte ich, die Dinger senden Kleinschreibung zurück, und das ist eigentlich auch das, was dein list hier aussagt...?
Da ich in einer Wiki noch nie was gemacht habe, bin ich da wohl leider der falsche Ansprechpartner :-\
Das OT schließen wir mal aus dem Thema ab, hatte mich einfach nur sehr gewundert.... Aber danke für die aufschlussreichen Antworten....
1. hmm verwirrt mich jetzt komplett wegen Antwort in 2.
2. Also sie sind mit Tasmota 6.6.0 geflasht. Das erste List in dem Posting davor zeigt ein Device nach direktem autocreate durch MQTT. D.h. so sah das Ding mehr oder weniger nackt aus, nach wenigen Minuten. Dort sieht man eben auch
2019-09-25 12:14:42 POWER OFF
2019-09-25 12:14:42 Switch1 OFF
also senden sie am Anfang erstmal Großbuchstaben. Das zweite List das ich geschickt habe, ist nach der Auswahl der Templates: "A_01z_tasmota_set_lowercase_texts_and_state1" und "A_01z_tasmota_set_power1_state_to_power" und am Ende "A10_Shelly" nacheinander. So habe ich das ursprünglich immer gemacht und es hat soweit super funktioniert, dass quasi die o.g. Vorraussetzungen erfüllt werden und alle Geräte immer die gleichen STATE und readings hatten ;)
p.s. Momentan kann ich das damit umgehen, dass ich ConfigBackup vom alten Device einspiele und die SetList und ReadingsList anpasse. Damit funktioniert es immernoch perfekt. Ist aber nicht im Sinne des Erfinders, weil ich ja auf Fortschritte, Ergänzungen und mögliche Bugfixes in der Modul / Templates etc verzichte.
Ah, ok, also umgeflasht. Dann sind die "shelly"-templates schlicht nicht mehr richtig, die benötigen die originale Firmware.
Nimm einfach "tasmota_basic" oder "tasmota_basic_state_power1" (läuft auf dasselbe raus). Das sollte alles erforderliche erledigen (nichts anderes vorneweg erforderlich, das ist "all inclusive" ;) ).
(Mach ggf. mal ein update, die Namen sind jetzt leicht anders, nachdem Rudi die Sortierung auf andere Art möglich gemacht hat als über den Namen).
Aaahhhhhh das erklärt einiges....
ZitatAh, ok, also umgeflasht. Dann sind die "shelly"-templates schlicht nicht mehr richtig, die benötigen die originale Firmware.
Nimm einfach "tasmota_basic" oder "tasmota_basic_state_power1" (läuft auf dasselbe raus). Das sollte alles erforderliche erledigen (nichts anderes vorneweg erforderlich, das ist "all inclusive" ;) ).
Perfekt... ich hab hier eh noch 2 komplett nackte bei den ich das testen kann
Vielen Dank, hast mir damit sehr geholfen. Werde es testen und berichten, falls erwünscht :)
Warum umflashen?
Das ergibt nicht mehr Funktionalität, aber der Versicherungschutz ist hin... (Ok, ziemlich theoretisch..., aber trotzdem: Einfach auf MQTT stellen, das nach-Hause-telefonieren ggf. unterbinden und gut ist).
Zitat von: Beta-User am 25 September 2019, 14:43:19
Einfach auf MQTT stellen, das nach-Hause-telefonieren ggf. unterbinden und gut ist).
Genau das ist mein Problem ... ich bin da schon etwas paranoid, was manche da so zusammen sammeln.
Imho war es doch so, dass man mit der Original Software MQTT aktivieren kann, dafür aber die originale App braucht und das nach Hause telefonieren nicht unterbindet?
Wenn es sich anders bewerkstelligen lässt, bin ich ganz Ohr. Ich brauche ja wirklich lediglich die on(for timer) off und MQTT Funktionen. Alles andere stelle ich ab (das ist hier dann auch für mich die Entscheidung für Tasmota)
Das mit der Versicherung ist ja so eine Sache: Ich greife ja in die Kommunikation ein, nicht in die Hardwareseitige Steuerung ? Dh das Ding macht ja weiterhin on off, wie im original auch?
Grüße
Andreas
Nu ja, du veränderst mir der firmware schon die Hardware, was aber bei einem Relais nicht dramatisch sein sollte. Bei zweien ist das uU. was anderes, und ob da z.B. intern eine Leistungsbegrenzung eingebaut ist usw. weiß ich nicht. Aber wenn z.B. so eine Schutzfunktion eingebaut wäre, die du deaktivierst, wäre es kontraproduktiv...
Ich habe keine Shelly, aber mWn. haben die ein WEB-Interface, in dem sich ein "local mode" einstellen läßt, ganz ohne App. Man kann auch das GW ins i-net umstellen usw.. Das sollte für Paranoiker reichen (ich meine, pah hätte das mal irgendwo erläutert, aber ich müßte das auch suchen).
Und SetExtensions@MQTT2_DEVICE ist unabhängig von shelly/tasmota, wobei es @tasmota auch eine "backlog"-Implementierung gibt und @shelly eine mit pah's Modul, die den Timer auf das Device verlagern (der also weiterläuft, selbst wenn FHEM weg ist).