Ich bin grad dabei, mich in Tasmota einzuarbeiten und habe dazu meinen Sonoff TH geflasht, der die Warmwasserpumpe dann temperaturgradientenabhängig schalten soll.
Das Relais lässt sich per WebIF schalten und der Status wird nach FHEM übertragen, schalten per fhem on/off geht noch nicht. Wo könnte es da noch klemmen?
mein Device:
defmod sonoffww MQTT_DEVICE
attr sonoffww IODev mqtt
attr sonoffww autoSubscribeReadings 1
attr sonoffww devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr sonoffww icon hue_filled_br30
attr sonoffww publishSet ON OFF cmnd/sonoffww/POWER/set
attr sonoffww room MQTT
attr sonoffww stateFormat transmission-state
attr sonoffww subscribeReading_Pumpe stat/sonoffww/POWER/set
attr sonoffww subscribeReading_Sensor tele/sonoffww/SENSOR
attr sonoffww subscribeReading_Status stat/sonoffww/STATUS
attr sonoffww webCmd ON:OFF
setstate sonoffww subscribe sent
setstate sonoffww 2017-08-16 15:07:59 Pumpe OFF
setstate sonoffww 2017-08-16 15:10:15 state OFF
setstate sonoffww 2017-08-16 16:55:50 transmission-state subscribe sent
Die Temperatur eines angeschlossenen DS18B20 Sensors wird auch schon in WebIF angezeigt und als MQTT Telegramm übertragen. Ich hätte aber gerne wesentlich häufiger den Wert, um die Pumpe zeitnah einschalten zu können, wenn Warmwasser bezogen wird.
Wo kann ich das einstellen?
Auch wird die Temperatur im FHEM noch nicht angezeigt. Brauch ich da ein stateformat? Den JSON Filter habe ich angelegt, weiß aber nicht so recht weiter.
defmod JSON expandJSON S|sonoff.*:.*:.{.*} (Power|Current|Voltage|Yesterday|Today|AnalogInput0|RSSI|.*Humidity|.*Temperature)
attr JSON room MQTT
setstate JSON active
setstate JSON 2017-08-16 15:07:29 state active
Dann würde ich gern noch weitere Temperaturen an der Heizung messen, das geht aber nicht (weitere DS18B20 parallel).
kann Tasmota mehr als einen DS18B20 oder nur einen?
Herzlichen Dank für eure Unterstützung ;D
Ich habe für den gleichen Zweck einen Testaufbau mit ESPEasy gemacht.
Es sind 4 Devices angelegt:
Task1: DS18B20 Vorlauf Wärmepumpe, 15s Delay
Task2: DS18B20 Rücklauf Wärmepumpe, 15s Delay
Task3: Dummy Device "Wasser", Type Quad
Vorlauf
Ruecklauf
Delta
Pumpe
Task4: Dummy Device "Shift", Type Quad
reg1
reg2
reg3
reg4
Und hier die Rules:
On System#Boot do
// clear shifter
TaskValueSet 4,1,0
TaskValueSet 4,2,0
TaskValueSet 4,3,0
TaskValueSet 4,4,0
endon
On shifter do
// shift out reg1
TaskValueSet 4,4,[Shift#reg3]
TaskValueSet 4,3,[Shift#reg2]
TaskValueSet 4,2,[Shift#reg1]
endon
On pumpctrl do
if [Wasser#Delta]>0.4 // gradient for on
TaskValueSet 3,4,1 // Pumpe ein
endif
if [Wasser#Delta]<0.4 // gradient for off
TaskValueSet 3,4,0 // Pumpe aus
endif
endon
On Vorlauf#DS18B20_00DA do
TaskValueSet 3,1,%eventvalue%
event shifter
TaskValueSet 4,1,%eventvalue%
if [Shift#reg2]>[Shift#reg1]
TaskValueSet 3,3,0
else
TaskValueSet 3,3,[Shift#reg1]-[Shift#reg2]
endif
event pumpctrl
endon
On Ruecklauf#DS18B20_009F do
TaskValueSet 3, 2, %eventvalue%
endon
Im Anhang ein Screenshot vom Schaltverhalten.
Super, Danke @SusisStrolch !
Ich hatte bisher auch ESPEasy im Einsatz, hab aber über FHEM geschaltet und das war nicht so zuverlässig.
Da dachte ich mir, ich probiers mal mit Tasmota / MQTT.
Ich werde wohl deine Lösung mit den Rules für mich adaptieren.
Trotzdem interessiert mich, wo jetzt noch der Haken beim MQTT_DEVICE ist. Ich kriege keine Readings im FHEM.
zum schalten versuch das mal:
attr sonoffww publishSet ON OFF cmnd/sonoffww/power
und für die Daten müsste man wissen ob die im gerät schon erzeugt werden und/oder ob die im MQTT ankommen...
Zitat von: SamNitro am 16 August 2017, 20:55:48
zum schalten versuch das mal:
attr sonoffww publishSet ON OFF cmnd/sonoffww/power
und für die Daten müsste man wissen ob die im gerät schon erzeugt werden und/oder ob die im MQTT ankommen...
ok, damit schaltet er ein und direkt wieder aus:
mosquitto_sub -d -v -t \#
stat/sonoffww/RESULT {"POWER":"ON"}
Client mosqsub|17233-raspberry received PUBLISH (d0, q0, r0, m0, 'stat/sonoffww/POWER', ... (2 bytes))
stat/sonoffww/POWER ON
Client mosqsub|17233-raspberry received PUBLISH (d0, q0, r0, m0, 'stat/sonoffww/RESULT', ... (15 bytes))
stat/sonoffww/RESULT {"POWER":"OFF"}
Client mosqsub|17233-raspberry received PUBLISH (d0, q0, r0, m0, 'stat/sonoffww/POWER', ... (3 bytes))
stat/sonoffww/POWER OFF
Edit: Konsole vom Modul:
19:59:43 MQTT: stat/sonoffww/RESULT = {"POWER":"ON"}
19:59:43 MQTT: stat/sonoffww/POWER = ON
19:59:44 MQTT: stat/sonoffww/RESULT = {"POWER":"OFF"}
19:59:44 MQTT: stat/sonoffww/POWER = OFF
Geht er auch direkt wieder aus wenn du ihn am Gerät schaltest?
Welches Gerät hast du eingerichtet in den Optionen? Sonoff th?
Gesendet von iPhone mit Tapatalk
Ja (mit webIF, der Schalter ist kaputt) und ja, th
Gesendet von meinem SM-P600 mit Tapatalk
Gib mal bitte das Ergebnis von
-PulseTime
-SwitchMode
Aus der Console
10:01:49 CMND: pulsetime
10:01:49 MQTT: stat/sonoffww/RESULT = {"PulseTime1":10}
10:02:34 CMND: switchmode
10:02:34 MQTT: stat/sonoffww/RESULT = {"Command":"Unknown"}
in der user_config.h hab ich
#define SWITCH_MODE TOGGLE
stehen.
mit PulseTime 10 wird nach 10 1/10 Sekunden automatisch wieder ausgeschaltet.
Entweder Pulsetime 0 oder einen vernünftigen Wert einstellen wenn Automatikbetrieb gewünscht ist.
PulseTime<x> Show current PulseTime of relay<x> in 0.1 seconds
PulseTime<x> 0 / off (Default) Disable use of PulseTime for relay<x>
PulseTime<x> 1..111 Set PulseTime for relay<x> with 0.1 seconds increment
PulseTime<x> 112..64900 Set PulseTime for relay<x> with 1 seconds increment starting with 12 seconds (113 = 13 seconds etc.)
LG
Super erklärt, Danke das war's.
Ich hab jetzt auf der console "pulsetime 160" eingegeben und die Pumpe schaltet nach einer Minute aus.
10:30:34 MQTT: stat/sonoffww/RESULT = {"POWER":"ON"}
10:30:34 MQTT: stat/sonoffww/POWER = ON
10:31:34 MQTT: stat/sonoffww/RESULT = {"POWER":"OFF"}
10:31:34 MQTT: stat/sonoffww/POWER = OFF
Das Temperaturreading wurde automatisch im FHEM Device angelegt, nachdem ich diverse attribute und readings gelöscht hatte.
mehrere Temperatursensoren gehen jetzt auch, nach Eintrag von
#define USE_DS18x20
letzter Stand des Devices:
Internals:
IODev mqtt
NAME sonoffww
NR 270
STATE Vorlauf: 48.1 C; Rücklauf: 43.3 C; PumpeWW: OFF ; incoming publish received ;
TYPE MQTT_DEVICE
qos 0
retain 0
Helper:
DBLOG:
DS18x20_DS1_Temperature:
DBLogging:
TIME 1503137184.14974
VALUE 48.1
DS18x20_DS2_Temperature:
DBLogging:
TIME 1503137184.14974
VALUE 43.3
Pumpe:
DBLogging:
TIME 1503136804.85091
VALUE OFF
READINGS:
2017-08-19 12:06:24 DS18x20_DS1_Temperature 48.1
2017-08-19 12:06:24 DS18x20_DS2_Temperature 43.3
2017-08-19 12:00:04 Pumpe OFF
2017-08-19 12:06:24 Sensor {"Time":"2017-08-19T11:06:24", "DS18x20":{"DS1":{"Type":"DS18B20", "Address":"28FFF6169015039A", "Temperature":48.1}, "DS2":{"Type":"DS18B20", "Address":"28FFBB139015049D", "Temperature":43.3}}, "TempUnit":"C"}
2017-08-19 12:06:24 Status {"Time":"2017-08-19T11:06:23", "Uptime":1, "Vcc":3.184, "POWER":"OFF", "Wifi":{"AP":1, "SSID":"MySSID", "RSSI":16, "APMac":"xx:xx:xx:xx:xx:xx"}}
2017-08-19 12:00:03 state OFF
2017-08-19 12:06:24 transmission-state incoming publish received
message_ids:
publishSets:
:
topic cmnd/sonoffww/POWER
values:
ON
OFF
sets:
OFF
ON
subscribe:
stat/sonoffww/POWER/set
tele/sonoffww/SENSOR
stat/sonoffww/STATUS
stat/sonoffww/STATE
stat/sonoffww/POWER
tele/sonoffww/STATE
subscribeExpr:
^stat\/sonoffww\/POWER\/set$
^tele\/sonoffww\/SENSOR$
^stat\/sonoffww\/STATUS$
^stat\/sonoffww\/STATE$
^stat\/sonoffww\/POWER$
^tele\/sonoffww\/STATE$
subscribeReadings:
stat/sonoffww/POWER Pumpe
stat/sonoffww/POWER/set Pumpe
stat/sonoffww/STATE Status
stat/sonoffww/STATUS Status
tele/sonoffww/SENSOR Sensor
tele/sonoffww/STATE Status
Attributes:
DbLogInclude DS18x20_DS1_Temperature,DS18x20_DS2_Temperature,Pumpe
IODev mqtt
devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
icon hue_filled_br30
publishSet ON OFF cmnd/sonoffww/POWER
room Heizung,MQTT
stateFormat Vorlauf: DS18x20_DS1_Temperature C; Rücklauf: DS18x20_DS2_Temperature C; PumpeWW: Pumpe ; transmission-state ;
subscribeReading_Pumpe stat/sonoffww/POWER
subscribeReading_Sensor tele/sonoffww/SENSOR
subscribeReading_Status tele/sonoffww/STATE
webCmd ON:OFF
Was noch nicht geht ist das devstateicon. Da steht nur ON und OFF
und die Temperaturtelegramme kommen nur alle 5 Minuten.
Ja, Pulsetime ist etwas kompliziert weil es eine Doppelfunktion der Zeiteinheit hat (bis 111 und ab 112) .
wenn beim devstateicon nur Text steht, dann fehlen dir im Verzeichnis /opt/fhem/www/images/default die Icons. Checke das einmal, es sollten dort rc_RED, rc_GREEN und rc_OK liegen.
Entweder du wählst andere Icons oder nimmst die vom Anhang und kopierst sie an die richtige Stelle.
LG
Zitat von: SusisStrolch am 16 August 2017, 18:30:18
Ich habe für den gleichen Zweck einen Testaufbau mit ESPEasy gemacht.
...
Im Anhang ein Screenshot vom Schaltverhalten.
Ich habe das nachgebaut, aber leider startet mein ESP immer wieder neu.
Das sieht man z.B. an der uptime und daran, dass Delta dann nach dem Neustart für einen Zyklus gleich der aktuellen Temperatur ist.
Die Pumpe schaltet dann auch ein.
RSSI ist so -60-65. Kann das am Wifi liegen oder ist der ESP mit den Messungen und rechnen schon überfordert?
Kann ich mir fast nicht vorstellen...
Hinweise zur Fehlersuche sind willkommen, Danke!
Die hohe Auslastung hing offensichtlich mit dem "enable Serial Port" @115k unter Advanced Settings zusammen. :P
Nachdem ich das Häkchen rausgemacht habe, gibt es erstmal seit ein paar Stunden keine Reboots mehr.
Auslastung ist auf Werte 50-80% gesunken, v2.0.0-dev11.
ich habe mir deinen Eröffnungsthread jetzt genauer angesehen, so klappt das mit den neuen Versionen von Tasmota nicht mehr, hier wurde von Theo einiges geändert. Siehe Beispiel im Wiki (https://wiki.fhem.de/wiki/Sonoff#Einbindung_des_HC-SR501_in_FHEM) des PIR.
Ich werde das die nächsten Tage bei allen Beispielen überarbeiten und bei "MQTT und Tasmota" genau darauf hinweisen.
attr sonoffww publishSet ON OFF cmnd/sonoffww/POWER/set
alte Versionen vor Tasmota 5
attr sonoffww publishSet ON OFF cmnd/sonoffww/POWER
mit Tasmota 5 entfällt /set
LG
[/code]
[quote author=Reinhart link=topic=75484.msg679077#msg679077 date=1504166295]
mit Tasmota 5 entfällt /set
[/quote]
Danke Reinhart,
das hatte ich durch console und probieren schon rausgefunden.
Jetzt bin ich für die Warmwasser Pumpen Anwendung auf ESP-Easy umgestiegen, wie von @SusisStrolch vorgeschlagen,
weil MQTT zusätzliche Komplexität bringt.
Zudem erscheint mir die Relaisschaltung über FHEM unzuverlässiger als die Logik direkt im Modul.
Nun hab ich aber diese Reboot Probleme und wollte wissen, ob das mit ESPEasy 2.0 Beta zusammenhängt oder eher normal ist.
Die Temperaturmesszyklen sind auf 15 MinutenSekunden eingestellt und ich habe momentan nur 2 Sensoren aktiiv.
Jetzt habe ich die Rules mal rausgenommen und versuche so, den Verursacher der hohen Last einzugrenzen.
Edit: mit Auskommentierten Rules sinkt die Last auf ca. 15%. Mist, sieht so aus als müsste ich umflashen auf eine 1er Version.
Gruß
Für die Steuerung habe ich noch die Version 148 am Laufen.
RSSI ist - im wahrsten Sinne - im Keller: -80 - -85 dB
Die aktuelle Uptime liegt bei ~180h.
Danke @SusisStrolch, gut zu wissen. Dann liegts wohl eher nicht am WiFi Empfang bei -65 RSSI.
Die Systemlast ist jetzt bei ca 15%, also sind die Rules in Version 2 wohl etwas ineffizienter implementiert.
Ich werde wohl auf Version 1 downgraden müssen.
Bei 15% muss man sich keine Gedanken wg Downgrade machen.
Wie viele DS1820 hast Du dran?
im Moment physisch 4 Sensoren wovon 2 aktiv sind.
Das Problem ist: Sobald ich die Rules aktiviere, geht die Auslastung auf 100%, alle paar Stunden ein reboot. Die Funktion ist auch nicht wirklich gegeben.
Dev1: 1x DS18b20 Ruecklauf, GPIO-13, 15s Delay, Send Data
Dev2: 1x DS18b20 Vorlauf, GPIO-13, 15s Delay, Send Data
Dev3: 1x Dummy 'Wasser', Type Quad, 15s Delay, Send Data
Dev4: 1x Dummy 'Shift', Type Quad, 15s Delay, Send Data = no
Dev11: 1x sysinfo 'RSSI', 15s Delay, Send Data
Dev12: 1x sysinfo 'uptime', 15s Delay, Send Data
Load liegt um die 28%...
Danke!
bei mir:
Dev1: Switch Input Relais GPIO-12, 0s Delay, Send Data
Dev2: RSSI, 60s Delay, Send Data
Dev3: Switch GPIO-0 (Taster am Modul), 0s Delay, Send Data=no
Dev4: Switch-Input GPIO-13 (LED), 0s Delay, Send Data=no
Dev5: DS18b20: Vorlauf, 12Bit, GPIO-14, 15s Delay, Send Data
Dev6: DS18b20: Rücklauf, 9Bit, GPIO-14, 15s Delay, Send Data
Dev7: DS18b20: Kessel, 9Bit, GPIO-14, 60s Delay, Send Data
Dev8: DS18b20: WarmwasserSpeicher, 9Bit, GPIO-14, 60s Delay, Send Data
Dev9: Wie bei dir Dev3
Dev10: Wie bei dir Dev4
Dev11: Sysinfo: Load, 300s Delay, Send Data
Dev12: Sysinfo: Uptime, 600s Delay, Send Data
Ob Dev6-7 enabled sind, macht ca 5-10% load aus.
Hast du die R148 selbst kompiliert (z.B. Plugins rausgenommen)?
Hast du davon noch das binary?
kleiner Nachtrag:
ich habe versucht, die Rules maximal abzuspecken.
folgendes ist dabei herausgekommen:
on Vorlauf#Temperature do
if [%eventvalue%-Wasser#Vorlauf]>0.4
GPIO,12,1 // Pumpe an
timerSet,1,60 // Timer setzen
endif
TaskValueSet 9,1,%eventvalue% // aktuellen temperature Wert speichern
endon
on Rules#Timer=1
gpio,12,0 //Pumpe aus
endon
Kann das funktionieren oder seht ihr hier noch Fehler?
Danke!
Zitat von: Lucky2k12 am 01 September 2017, 16:19:05
Hast du die R148 selbst kompiliert (z.B. Plugins rausgenommen)?
Hast du davon noch das binary?
Ja - ist selbst kompilert, da ich mir noch nen S0-Zähler eingebaut habe.
Hmm - denke ja... Zumindest ist die ESPEasy.ino mit "148" getaggt...
Hier das Binary für ein NodeMCU - ich meine, das hätte ich mit 3MB Code / 1MB Spiffs compiliert.
Zitat von: Lucky2k12 am 01 September 2017, 20:08:54
Kann das funktionieren oder seht ihr hier noch Fehler?
Danke!
Poste bitte mal den kompletten Ruleset, ansonsten sieht man "nur Fehler" :)
Danke für die .bin! ;D
Zitat von: SusisStrolch am 02 September 2017, 11:42:26
Poste bitte mal den kompletten Ruleset, ansonsten sieht man "nur Fehler" :)
Das war der ganze aktive Ruleset :'(
Die Idee ist:
Ich schreibe nur den aktuellen Wert in das erste Register von Dummy
Wenn ein neuer Wert kommt, schaue ich mir die Differenz an.
Wenn die größer als der Schwellwert ist, schalte ich die Pumpe ein und setze einen Timer.
Wenn der Timer abläuft, schalte ich die Pumpe wieder aus.
Das läuft momentan bei ca 30% load mit 10sec Intervall beim Vorlauf.
Wie kann ich das eigentlich debuggen? Das log scheint mir nicht sehr gesprächig.
Boah... um 11:00 sollte man eigentlich wach sein ;)
Jo - passt aus meiner Sicht so. Das "Schieberegister" ist bei mir noch ein Überbleibsel aus alten Test-Zeiten, wo mir noch nicht klar war, wie schnell sich die Vorlauftemperatur beim Einschalten ändert.
Zitat von: SusisStrolch am 02 September 2017, 11:08:42
Ja - ist selbst kompilert, da ich mir noch nen S0-Zähler eingebaut habe.
Hmm - denke ja... Zumindest ist die ESPEasy.ino mit "148" getaggt...
Hier das Binary für ein NodeMCU - ich meine, das hätte ich mit 3MB Code / 1MB Spiffs compiliert.
Mit meinen vereinfachten Rules hatte ich unter 2.0.0. dev 11 keine reboots mehr bei einem Load von 25-40%.
Leider konnte ich auch nichts mehr an meinen Rules oder Devices ändern, jedesmal die Meldung "Error saving to flash!", auch nach 24 h Wartezeit :(
S0 hätte mir ganz gut gepasst, weil mein ATTINY OWCOUNTER Emulator von locutus mit dem neuen OWX NG nicht mehr erkannt wird. Da kommen nur noch CRC Fehler. Das EEPROM ist wahrscheinlich nicht nach Datenblatt. Egal, das ist hier offtopic.
Ich hab die Firmware, die du gepostet hast, eben aufgespielt, komm aber nicht in die Konfiguration (PW ist nicht configesp).
Ich denke, ich werde mich mal mit der ATOM / PlatformIO Config beschftigen und die 1.48 selbst neu kompilieren.
Zitat von: Lucky2k12 am 05 September 2017, 20:23:58
Ich hab die Firmware, die du gepostet hast, eben aufgespielt, komm aber nicht in die Konfiguration (PW ist nicht configesp).
Ich denke, ich werde mich mal mit der ATOM / PlatformIO Config beschftigen und die 1.48 selbst neu kompilieren.
Das Passwort ist unverändert - 'configesp'...
Schau mal unter "https://github.com/susisstrolch/ESPEasy/commits/S0-Counter" - der läuft bei mir schon seit Jan/Feb...
Ok Super, heute hat es auch mit dem PW funktioniert :)
Deine Version produziert beim identischen Setup nur < 10% Load ! Freu 8)
BTW: Was hast du eigentlich am PulseCounter optimiert?
Gruß
Optimierungen:
Counter-Werte werden Reset-sicher gespeichert
Glitch-Schwelle lässt sich übers Menu einstellen
Messwerte werden sofort (+0.1s) gesendet, nicht nur im Sensor-Delay Interval
Preset-Möglichkeit für die Counter (wg 1. Punkt)
Ich weiss jetzt nicht genau, ob dies schon in dem Image drinne ist, welches ich hochgeladen habe.
Nach meinem Urlaub werde ich mich da mal drum kümmern.
Btw, für die DS18B20 gibts momentan einen Pull-Request, welcher die Last doch ziemlich reduzieren sollte.
Momentan hat das Plugin ~800ms Delay für -jeden- angeschlossenen Sensor...
Danke! Couter Werte speichern und Sensor-Delay hört sich sehr gut an.
Ich häng hier schon wieder.
Ich hatte jetzt auch mit deiner Firmware die Meldung, dass er nix mehr speichern kann und 101 Flashzähler auf der Info-Seite, obwohl ich nix geändert hatte in den letzten 24h.
Ausserdem hat er immer noch Version 2.0.0 dev11 gemeldet.
Also habe ich versucht, nach der Anleitung von Pf@nne? den ESP komplett zu löschen und neu zu flashen mit deiner .bin
Er spannt auch ein WLAN auf, aber ich komm mit dem Browser nicht auf die Konfigurations-Seite.
In der seriellen Konsole kommt folgendes bevor er den WLAN AP aufspannt:
ets Jan 8 2013,rst cause:1, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld
▒U
PID:0
Version:0
INIT : Incorrect PID or version!
RESET: Reboot count: 1
FLASH: Erase Sector: 106
FLASH: Erase Sector: 107
FLASH: Erase Sector: 108
...
FLASH: Erase Sector: 255
FLASH: Settings saved
FLASH: Settings saved
ets Jan 8 2013,rst cause:1, boot mode:(3,7)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09826c6d
~ld
▒U
PID:0
Version:0
INIT : Incorrect PID or version!
RESET: Reboot count: 4
RESET: To many reset attempts
Entered Rescue mode!
Was kann ich da tun?
Gruß
Welchen ESP verwendest Du?
Das .bin ist für 4MB QIO compiliert...
Bin wohl zu doof das Subject zu lesen... :(
Im Anhang ein .bin für den Sonoff...