Zu1: Alles gut. Hab drüber geschmunzelt. Ich denke die Lamppe kann dann mal in den Schrott. Wüßte nicht wie man Tasmota da resetten kann. Schade
In dem Fall würde ich versuchen sie zu zerlegen .... Schlimmer kann mans dann ja nicht machen
Zu1: Alles gut. Hab drüber geschmunzelt. Ich denke die Lamppe kann dann mal in den Schrott. Wüßte nicht wie man Tasmota da resetten kann. Schade
In dem Fall würde ich versuchen sie zu zerlegen .... Schlimmer kann mans dann ja nicht machen
Hi
vielleicht hat das einer von Euch auch schon gehabt. Ich kann mir da keinen rechten Reim drauf machen und hab das jetzt nicht zum 1. mal.
Ich erstelle ein firmware.bin mit dem Onlinecompiler, aktuell die 9.1.0
Flashe dieses mit FTDI auf ein Sonoff Gerät (flash wird vorher natürlich gelöscht und auch noch das blank.bin drüber geflasht) ... derzeit ein Touch T1 2Ch, hatte das aber auch schon bei Basic's.
Das Gerät läuft nach dem flash einwandfrei. Nur Firmwareupdates werden über's WebIF hartnäckig verweigert. Selbst die Minimal mit dem gleichen FW Stand 9.1.0 wird mit Upload Buffer Vergleich weicht ab verweigert.
WARUM ???
EDIT:
Oke ... ich wollte es einfach nicht glauben aber es ist tatsächlich die Größe, selbst beim minimal.bin.
Sobald ich das Ganze gzippe klappt es .... *nerv
Na, vielleicht hilft das ja irgendjemanden,
zu2. Bestellt habe ich diese. Dementsprechend habe ich auch dieses Template
{"NAME":"Lumary TS3Y","GPIO":[0,0,0,0,0,0,0,0,0,37,0,0,0],"FLAG":0,"BASE":18}
eingefügt. Nichs desto Trotz werde ich deinen Vorschlag mal testen.
Hmmm ... das sollte dann eigentlich passen, wenn die von Lumary dann doch nicht was an geändert haben. Kennt man ja von den Sonoff auch mit neuen versionen ...
Ich fürchte dann wirst du mal spielen müssen mit den Einstellungen. Schätze aber mal, das wirst du schon längst gemacht haben.
zu1. Wo hänge ich da den FTDI dran?
Eine sehr gute Frage !!! Wie man die Filament aufbringen soll ... da spuckt selbst der google nix zu aus. Und was man findet sieht eher nach Vandalismus aus als nach disassemble ... Ne, war nicht wirklich durchdacht mein Kommentar
Zuerst die Shutter Unterstützung aktivieren:
setoption80 1
Was passiert denn wenn du nur einfach shuttermode eingibst in der Konsole?
(ich kann es derzeit nicht überprüfen)
********************
EDIT:
ah, jepp zur Sicherheit nochmal geschaut
shuttermode 1
in der Konsole eingeben
********************
Wichtig ist das der Interlock eingeschaltet ist:
interlock 1
Wenn du in der Konsole einfach nur "interlock" eingibst bekommst du den status von interlock angezeigt.
Sobald Interlock on, Groups 1,2" dort steht sind die Relais gegeneinander veriegelt
Hi,
steht alles hier:
https://tasmota.github.io/docs/Blinds-and-Shutters/
In Deinem Fall shuttermode1 mit aktivem Interlock.
Mit der Original-Firmware sollte es eigentlich auch klappen, denke ich.
Nicht unbedingt. Das kommt auf den RF Code an. Die RF-Bridge unterstützt standart mäßig nur die Sonoff Frequenzen.
Da gibt's aber auch noch ne Menge andere außenherum. 433MHz ist nicht gleich 433MHz
Deswegen gibt es auch den Portisch Code, sprich die Möglichkeit nicht nur die Bridge auf Tasmota zu flashen sondern auch die den RF Teil der Bridge auf den erweiterten Frequenzbereich.
Und von rollierenden Codes haben wir noch gar nicht gesprochen. Sprich wenn der RF Code sich aus Sicherheitsgründen bei jedem Senden ändert.
Das ist dann mit der RF Bridge überhaupt nicht abzufangen.
Mein Fazit:
Viel Aufwand und Experimentieren und Einarbeiten mit zweifelhaften Erfolg.
Ich würde diese Energie eher in vernünftiges Smarthome investieren (Sonoff, Alexa fähige Geräte) wie es Supermicha schon erwähnt hat.
Auch das es keine Rückmeldung bei 433MHz Technik gibt, macht auf Dauer keinen Spaß, denn wenn Du auf den Geschmack von Sprachsteuerung kommst und Smarthome, wird es eh nicht lange dauern bis du mehr davon haben willst und spätestens da schmeißt Du dann die RF-Geschichte raus.
2. Bei der zweiten komme ich auf die GUI kann die Lampe z.b. auch ein oder ausschalten oder sonstige Einstellungen vornehmen, jedoch glimmen die LED's bei sehr genauem hinsehen nur.
Zuerst zu 2.
Ich vermute das das ne CCT Bulb ist, weil ja RGB usw.
In Deinem Template ist nur ein PWM konfiguriert. Die ganzen CCT Bulbs haben meisten zwei Gpio's auf PWM.
Versuch mal sowas:
https://templates.blakadder.com/ajax_online_7w_filament.html
Zu 1.
Wie hast du gefasht? Hardware? Tuya? Klingt nach unsauberem Flashvorgang. FTDI ran, blank.bin flashen und nochmal Tasmota drauf.
Das Tuya die Sicherheitslücke geschlossen hat ist sicher für die gut, verkaufsfördernd für ist das nicht.
In Zwischensteckern herumlöten ist wohl auch nicht die Lösung und ausserdem gefährlich.
Wenn Delock einen anderen Weg geht ist das auch Ihre Sache, es ist aber damit nicht mehr quellenoffen!
Wenn ich Orginal-Tasmota auf diesen Geräten aktualisiere und anschliessend die gesicherte Konfiguration einspiele ist das Gerät nur noch Schrott! Das dazu.
Ich bin nur besorgt das die wirklich gute Tasmota-Software von den Hardware-Herstellern verhindert wird.
Ist zwar alles Off Topic ...
Naja ... das ist alles Ansichtssache.
- verkaufsfördend - Für Aluhutträger die Orginal-FW verwenden, definitv ein Argument wieder Tuya zu kaufen.
- herumlöten - Tasmota ist nun mal etwas für Bastler. Wer sich das nicht zutraut, für den gibt es fertig geflashte Geräte zu kaufen und gefährlich ist das herumlöten nur wenn man nicht weiß was man macht.
- quelloffen - deswegen Tasmota!
- Warum sollte das Gerät Schrott sein? Selbst wenn mal was schief geht beim zurückschreiben von Konfigurationsbackup's ... dann sind wir eben wieder beim Thema basteln und harwareseitiges flashen. Tasmota eignet sich eher für Leute die Spaß am basteln haben und das auch möchte. Wer das lieber nicht möchte ist besser bei Orginal FW aufgehoben. Tuya Hack, hin oder her, das hardwareseitiges flashen besser und sicherer ist, war von Anfang an so.
- Tasmota verhindern? Wie sollte das gehen? Tasmota basiert auf dem ESP Chip oder baugleich. Solange man an die Pin's kommt geht der auch zu flashen.
Wie gesagt ... Philosophiefrage.
wie siehst mit ner Rule aus?
wenn poweron dann rgb xxxxx
wie die Rule dann genau lautet, da muss ich aber passen.
Die LED's werden ja von GPIO's nur geschaltet und sind den/dem Relais zugeordnet. Also kein PWM
Ließe sich nur mit ner Rule ansteuern wenn man die LED-GPIO als Relais definiert, oder so ... dann hat man aber auch für jede LED einen Webbutton. Nicht so toll, denke ich.
Die Waschmaschine meiner Frau zeigt auf dem Display genau an, wie lange sie braucht... also die Waschmaschine, nicht meine Frau...
Du willst doch wissen wann die Maschine OHNE Knitterschutz fertig ist, oder?
Ich denke er möchte wenn der komplette Vorgang mitsamt Knitterschutzphase abgeschlossen ist eine Meldung haben.
Ihn irritieren nur die dynamischen Pausenzeiten zwischen den Knitterschutzläufen.
Wie gesagt ... dazu einfach den Ruletimer größer als die größte Pausenzeit machen und dann passt das.
EDIT:
Du willst doch wissen wann die Maschine OHNE Knitterschutz fertig ist, oder?
Du hast recht, ich hab das auch falsch gelesen.
Ich fürchte fast das läßt sich nicht zuverläßig lösen. Man könnte ja auch die Minimalzeit in die Rule nehmen. Sobald der Power Wert eine gewisse kurze Zeit unter ein Limit fällt wird der MQTT Befehl ausgelöst. Nur ich befürchte das die Waschmaschine sicherlich während des Waschvorganges auch Ruheizeiten hat in den die Wäsche nur einweicht und der Energiewert auf das gleiche Niveau fällt wie bei Waschmaschine fertig.
Wenn man das ausschließen kann .... dann einfach eine Zeitwert in der Rule wählen der kleiner ist als die erste PAusenzeit.
ZitatRfRaw <value> = hexadecimal data to be sent to RF chip. This must be immediately followed by the RfRaw 0 command (e.g., Backlog RfRaw <value>; RfRaw 0
Die läuft 30min nach Beendigung des Waschprogramms. Dazu noch die 10min, sprich erst mindestens 40min später kommt die Meldung
Naja dann setz doch einfach den Ruletimer aus dem Beispiel auf eine Zeit die höher als die maximale Pause zwischen den Knitterschutzläufen ist.... Dann wird immer nachgetriggert und erst wenn die Zeit ohne erneuten Anlauf um ist wird gemeldet.
Ich kann leider nichts zum portisch sagen in der Praxis.
Aber mir fällt auf das du nach deinem konvertierten Code kein
RfRaw 0
Sendest .... Vergessen hier mit zu posten? Oder wirklich vergessen?
Der benzino TasmoCompiler läuft wieder mit der Development.
Ich tippe immer noch auf den Upstream.
Hast du spaßeshalber in der FB mal unter Internet/DSL-Informationen/Störsicherheit gespielt?
Senderichtung auf maximale stabilität gestellt, z.b.?
Und unter Statistik mal nach Störungen geschaut?
Das geht im benzino online compiler meines Wissens nicht.
Geht aber im gitpod. Da lassen sich Files ändern und ergänzen.
https://gitpod.io/#https://githu…ree/development
https://gitpod.io/#https://githu…ota/tree/master
https://tasmota.github.io/docs/Gitpod/
compilieren dann mit:
platformio run -e tasmota-DE
Das File liegt dann unter:
.pio/build/tasmota-DE/firmware.bin
Aber da kann ich auch nichts näheres zu sagen ....
Hi.
stimmt... crashed mit der development.
Stell mal Tasmota Version auf 8.5.1 dann läuft es durch.
Und wenn du schon dabei bist am besten Sprache auch noch einstellen
Wow !!!
Danke für die Info. Das wird künftig viele Sonderanwendungen sehr erleichtern und vor allem GPIO's sparen