Fragen zur MQTT2-Device Template Zuweisung

Begonnen von oehi86, 01 August 2019, 17:35:42

Vorheriges Thema - Nächstes Thema

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flummy1978

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 :)

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flummy1978

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

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors