Hallo,
habe folgendes Problem und zwar habe ich einen Nodemcu mit Tasmota geflasht und in Fhem über MQTT eingebunden.
Die 2 Relais lassen sich ansteuern.
Nun möchte ich 2 Buttons am Board anschließen welche folgendes schalten.
Button1- > Relay1 an und Relay2 an
Button 2 -> Relay 1 an und Relay 2 aus
Wenn ich einen Button konfiguriere schaltet Button1 Relay1 Button 2 Relay2 usw.
Wie bekomme ich das getrennt ?
Ich habe nun schon über Stunden Sachen durchgelesen doch irgendwie komme ich damit nicht klar.
Auch das Tasmota Wiki mit den ganzen verschiedenen Befehlen für die Schalter...
Vielleicht kann jemand helfen...
Das Trennen sollte mit SetOption1 bzw. 11 gehen, siehe https://tasmota.github.io/docs/Buttons-and-Switches/#changing-default-functionality.
Vermutlich brauchst du dann für den Rest rules, die basics dazu sollten hier stehen: https://tasmota.github.io/docs/Rules/#button-single-press-double-press-and-hold
ABER: Mir kommt das Anwendungsszenario irgendwie unvollständig vor. Willst du wirklich immer einschalten? Oder irgendwie auch wieder (teilweise?) aus?
Dann brauchst du irgendeine erweiterte Logik oder zumindest weitere Tastendrücke+rules...
Falls das irgendwie dafür gedacht ist, einen Rollladen zu steuern: Dafür gibt es interne Verriegelungsmechanismen und auch eine Kalibirerung innerhalb der Tasmota-Firmware ;) .
Hi,
ja ich möchte damit mein Rolltor ansteuern Button1 hoch 2 Runter und evtl. einen 3. für Stop.
Ich hatt gelesen das ich die Relais hardwaremäßig verriegel also quasi 1. Relai an das 2. Anschließe und so erst Relai 1. Einschalte und somit das 2. mit Strom versorgt wird und anschließend das 2. dann entsprechend der Laufrichtung geschaltet werden muss?
Wenn das noch einfacher geht wäre das natürlich genial.
Wichtig ist nur das nicht irgendwas passiert und der Antrieb abraucht, dann wirds teuer denn es ist ein 3 Phasen Industrierolltor was über 230 V Impulse über Relais angesteuert wird.
Sieh dir mal die tasmota Option interlock an. Damit kann man relais gegeneinander verriegeln
Your device must have at least two relays (see Shutters with Sonoff Dual R2). Only available in normal tasmota.bin!
Habe mir das grade mal angeschaut, stolpere ich gleich über diesesn Satz
Ich habe trasmota-sensors.bin geflasht weil ich noch einen BMP280 verbaut habe.
Also kann ich das so vergessen ? Mit der normalen tasmota.bin wurde mir der Sensor nicht angezeigt :(
Ist doch kein Problem.....die Meldung sagt dir doch, dass du keine relais angelegt hast
Es ist die Tasmonta Sensors.bin geflasht.
Ich habe 2 Relais angeschlossen und einen BMP280. Die Relais lassen sich ganz normal schalten die Temperatur und der Druck wird angzeigt.
Wenn ich nur die Tasmota.bin flashe funktioniert der TempSensor nicht mehr. Ich kann sie zwar kofigurieren aber es werden keine Werte angezeigt.
Im WIKI Shutters steht:
Your device must have at least two relays (see Shutters with Sonoff Dual R2). Only available in normal tasmota.bin!
Also funktioniert das mit meiner tasmota-sensors.bin nicht oder sehe ich das falsch.
Es geht vermutlich um die shutter-Funktionalität. Die braucht wg. der Timer etc.wohl etwas Speicher (wie der BME-Code), so dass es eben in der "normalen" nur eine der beiden Funktionalitäten gibt.
Ergo: Entscheiden, welche, zwei ESP nehmen oder selber compilieren (die firmware ist so konzipiert, dass sie auch auf "kleine" paßt; die meisten ESP haben aber mehr Speicher)...
Würde mal empfehlen, das mit der shutter-Funktionalität erst mal auf einem anderen ESP anzusehen, weil es uU. schon Sinn macht, eine HW-seitige Verriegelung vorzusehen. Ob die aber mit Tasmota-interner Funktionalität (ohne rules/interlock etc) abgebildet werden kann, kann man doch vorher mal rausfieseln?
Ist alles mit pulsetime und interlock zu erschlagen
Hallo ghostrider,
du hast uns noch nicht vollständig über deine Hardware aufgeklärt, außer über die Nodemcu, die du einsetzt.
Wenn du separate, externe Relais hast, kannst du sie hardwaremäßig gegeneinander verriegeln; das ist sicherer als eine softwaremäßige Lösung.
Für die hardwaremäßige Verriegelung gibt es mehrere Varianten, noch ein Hinweis, die Relais sollten bei Nichtbenutzung in der Position stehen, in der sie keine Energie benötigen.
Wir gehen im Beispiel von NC (normally closed) als energielose Position aus.
Relais1 schaltet nur Strom an oder aus:
NO des Relais 1 wird mit dem Eingang von Relais2 verbunden, das für das Hoch- oder Runterfahren zuständig ist, z.B. so:
Dann noch eine Frage zu deinem Rolltor. Ich kenne da nur 1-Knopf-Bedienungen: hoch-stop-runter usw., bei jedem Knopfdruck wird gestoppt, wenn in Fahrt, oder in Gegenrichtung gefahren, wenn in Endposition.
Hast du tatsächlich für jede Fahrtrichtung ein separates Relais? Bitte mehr Input zu deiner Hardware.
Viele Grüße Gisbert
Zitat von: Gisbert am 26 November 2020, 10:13:36
Relais1 schaltet nur Strom an oder aus:
NO des Relais 1 wird mit dem Eingang von Relais2 verbunden, das für das Hoch- oder Runterfahren zuständig ist, z.B. so:
...hier eine Veranschaulichung oder Verdrahtungsbeispiel zur hardwaremässigen Verriegelung:
https://forum.fhem.de/index.php/topic,88615.msg810907.html#msg810907
LG
Papa Romeo
Zitat von: Gisbert am 26 November 2020, 10:13:36
Hallo ghostrider,
du hast uns noch nicht vollständig über deine Hardware aufgeklärt, außer über die Nodemcu, die du einsetzt.
Wenn du separate, externe Relais hast, kannst du sie hardwaremäßig gegeneinander verriegeln; das ist sicherer als eine softwaremäßige Lösung.
Für die hardwaremäßige Verriegelung gibt es mehrere Varianten, noch ein Hinweis, die Relais sollten bei Nichtbenutzung in der Position stehen, in der sie keine Energie benötigen.
Wir gehen im Beispiel von NC (normally closed) als energielose Position aus.
Relais1 schaltet nur Strom an oder aus:
NO des Relais 1 wird mit dem Eingang von Relais2 verbunden, das für das Hoch- oder Runterfahren zuständig ist, z.B. so:
Dann noch eine Frage zu deinem Rolltor. Ich kenne da nur 1-Knopf-Bedienungen: hoch-stop-runter usw., bei jedem Knopfdruck wird gestoppt, wenn in Fahrt, oder in Gegenrichtung gefahren, wenn in Endposition.
Hast du tatsächlich für jede Fahrtrichtung ein separates Relais? Bitte mehr Input zu deiner Hardware.
Viele Grüße Gisbert
Hallo Gisbert,
wie beschrieben habe ich einen NodeMCU+2 Relais-Karte+BMP280 Sensor. Es ist die tasmota.sensor.bin geflasht da ich sonst keine Sensoren abfragen konnte.
Das ist meine Definition in FHEM für den NodeMCU
defmod MQTT2_DVES_2333B4 MQTT2_DEVICE DVES_2333B4
attr MQTT2_DVES_2333B4 IODev myBroker
attr MQTT2_DVES_2333B4 autocreate 0
attr MQTT2_DVES_2333B4 comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/cmnd/DVES_2333B4/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_DVES_2333B4 devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot 1.on:on:POWER1+off 1.off:off:POWER1+on 2.on:on:POWER2+off 2.off:off:POWER2+on
attr MQTT2_DVES_2333B4 icon hue_filled_outlet
attr MQTT2_DVES_2333B4 model tasmota_2ch_unified
attr MQTT2_DVES_2333B4 readingList tele/DVES_2333B4/LWT:.* LWT\
tele/DVES_2333B4/STATE:.* { json2nameValue($EVENT) }\
tele/DVES_2333B4/SENSOR:.* { json2nameValue($EVENT) }\
tele/DVES_2333B4/INFO.:.* { json2nameValue($EVENT) }\
stat/DVES_2333B4/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }\
tele/DVES_2333B4/UPTIME:.* { json2nameValue($EVENT) }\
stat/DVES_2333B4/POWER1:.* POWER1\
stat/DVES_2333B4/POWER2:.* POWER2
attr MQTT2_DVES_2333B4 room MQTT2_DEVICE
attr MQTT2_DVES_2333B4 setList POWER1:on,off,toggle cmnd/DVES_2333B4/POWER1 $EVTPART1\
POWER2:on,off,toggle cmnd/DVES_2333B4/POWER2 $EVTPART1\
attr MQTT2_DVES_2333B4 setStateList on off toggle
attr MQTT2_DVES_2333B4 stateFormat LWT\
1:POWER1\
2:POWER2\
<br>\
Temperatur BMP280_Temperature\
Luftdruck BMP280_Pressure\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>\
attr MQTT2_DVES_2333B4 webCmd POWER1:POWER2
setstate MQTT2_DVES_2333B4 Online\
1:off\
2:off\
<br>\
Temperatur 25.8\
Luftdruck 626.9\
<br>\
<a href="http://192.168.178.61" target="_blank">192.168.178.61</a>\
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 BMP280_Pressure 626.9
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 BMP280_Temperature 25.8
setstate MQTT2_DVES_2333B4 2020-11-25 12:30:23 ButtonTopic
setstate MQTT2_DVES_2333B4 2020-11-26 08:46:57 Command Unknown
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 Free 459
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Heap 22
setstate MQTT2_DVES_2333B4 2020-11-26 09:23:48 Hostname DVES_2333B4-5044
setstate MQTT2_DVES_2333B4 2020-11-26 09:23:48 IPAddress 192.168.178.61
setstate MQTT2_DVES_2333B4 2020-11-26 09:23:46 LWT Online
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 Length 52
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 LoadAvg 22
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 MqttCount 1
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 Once off
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 POWER1 off
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 POWER2 off
setstate MQTT2_DVES_2333B4 2020-11-25 09:44:40 POWER3 on
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 PressureUnit hPa
setstate MQTT2_DVES_2333B4 2020-11-26 09:23:48 RestartReason Software/System restart
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 Rule1 off
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 Rules on button1#state do backlog power1 2;; power2 2 endon
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:43 SaveData on
setstate MQTT2_DVES_2333B4 2020-11-26 11:20:15 SetOption114 on
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:43 SetOption26 on
setstate MQTT2_DVES_2333B4 2020-11-25 14:57:18 SetOption73 off
setstate MQTT2_DVES_2333B4 2020-11-26 08:44:03 SetOption80 on
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Sleep 50
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 SleepMode Dynamic
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:42 StateText1 off
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:42 StateText2 on
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:43 StateText3 toggle
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:43 StateText4 hold
setstate MQTT2_DVES_2333B4 2020-11-25 12:26:57 StopOnError off
setstate MQTT2_DVES_2333B4 2020-11-26 09:20:06 Switch1 off
setstate MQTT2_DVES_2333B4 2020-11-25 09:10:04 Switch2 on
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Switch3 off
setstate MQTT2_DVES_2333B4 2020-11-25 09:37:50 Switch8 on
setstate MQTT2_DVES_2333B4 2020-11-25 13:58:30 SwitchMode1 0
setstate MQTT2_DVES_2333B4 2020-11-25 13:58:40 SwitchMode2 0
setstate MQTT2_DVES_2333B4 2020-11-25 12:32:18 SwitchTopic
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 TempUnit C
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Time 2020-11-26T11:28:50
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Uptime 0T02:05:09
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 UptimeSec 7509
setstate MQTT2_DVES_2333B4 2020-11-26 09:23:48 WebServerMode Admin
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_AP 1
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_BSSId 34:31:C4:01:6C:7A
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_Channel 13
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_Downtime 0T00:00:03
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_LinkCount 1
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_RSSI 56
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_SSId FRITZ!Box 7490
setstate MQTT2_DVES_2333B4 2020-11-26 11:28:50 Wifi_Signal -72
setstate MQTT2_DVES_2333B4 2020-11-25 08:06:42 attrTemplateVersion 20200522 or prior
setstate MQTT2_DVES_2333B4 2020-11-25 08:08:30 subscriptions cmnd/DVES_2333B4/# cmnd/DVES_2333B4_fb/# cmnd/tasmotas/#
Das alleine hat mich schon tage gekostet weil ich einfach nicht mit den Templates zurecht komme und immer was anpassen wollte, z.B. das die Temp angezeigt wird und ich den zusätzlichen POWER2 angezeigt bekomme. :(
Oder diese Meldung, ich kapiere nicht was genau darein muss ? Das ist jetzt ein TEST-Gerät
pecify the unknown parameters for tasmota_basic_state_power1:
Command topic prefix, without trailing /
info topic prefix, without trailing /
ack topic prefix, without trailing /
Hier noch der Code für das Schalten aus FHEM heraus
defmod Scheunentor ROLLO
attr Scheunentor cmdIcon open:fts_shutter_up closed:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr Scheunentor devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
attr Scheunentor rl_autoStop 0
attr Scheunentor rl_commandDown set MQTT2_DVES_2333B4 POWER1 on;; set MQTT2_DVES_2333B4 POWER2 off
attr Scheunentor rl_commandStopDown set MQTT2_DVES_2333B4 POWER1 off;; set MQTT2_DVES_2333B4 POWER2 off
attr Scheunentor rl_commandStopUp set MQTT2_DVES_2333B4 POWER1 off;; set MQTT2_DVES_2333B4 POWER2 off
attr Scheunentor rl_commandUp set MQTT2_DVES_2333B4 POWER1 on;; set MQTT2_DVES_2333B4 POWER2 on
attr Scheunentor rl_excessBottom 2
attr Scheunentor rl_excessTop 4
attr Scheunentor rl_secondsDown 30
attr Scheunentor rl_secondsUp 30
attr Scheunentor rl_switchTime 1
attr Scheunentor rl_type normal
attr Scheunentor room Schalten
attr Scheunentor webCmd open:closed:half:stop:pct
setstate Scheunentor open
setstate Scheunentor 2020-11-25 09:41:30 command open
setstate Scheunentor 2020-11-25 09:41:30 desired_pct 0
setstate Scheunentor 2020-11-25 09:41:30 drive-type modul
setstate Scheunentor 2020-11-25 09:41:30 last_drive drive-up
setstate Scheunentor 2020-11-25 09:42:06 pct 0
setstate Scheunentor 2020-11-25 09:42:06 state open
Hier habe ich die Command up und down so bearbeitet wie ich es mir vorstelle.
Ein Relais Schaltet ein und ist an das zweite Relai angeschlossen welches jetzt zwischen runter und hoch hin und her schalten kann. Schaltet man das 1. Relais wieder aus ist das 2. stromlos.
Ich habe am Rolltor 3 Tasten 1. für hoch nochmal drücken stoppt 2. tasten für runter nochmal drücken stoppt. 3. Taste wäre eigentlich Stop hab ich aber grade nicht angeschlossen.
Die Relais im Antrieb sind momentan auf Selbsthaltung angeschlossen deswegen müssen die Taster nur kurz angetippt werden.
Ich verwende dafür derzeit die ELV Markisensteuerung welche aber nicht zufriedenstellend funktioniert, da man hier keine Rückmeldung über den Schaltzustand bekommt und man nicht noch mehr Sachen anschließen kann, also Katasrophe :)
Bin für jede Hilfe dankbar versuche zu verstehen bin leider aber nicht Fit auch wenn ich Passagen wieder und wieder durchlese zur Konfiguration...
Sorry, aber bei dem Kenntnisstand wäre meine Empfehlung, das auf zwei ESP's zu verteilen.
Das mit ROLLO und dem "softwaremäßigen Nachverriegeln" ist nicht optimal, und der Rollladen-Modus in Tasmota selbst ist dem Vernehmen nach super.
Wie dem auch sei: Die Rückfrage aus dem attrTemplate kommt daher, dass bestimmte Inhalte nicht automatisiert ermittelt werden können - hier, weil kein LWT-Eintrag in der readingList in deiner Test-Kopie enthalten gewesen sein dürfte.
Zitat von: Beta-User am 26 November 2020, 12:46:36
Sorry, aber bei dem Kenntnisstand wäre meine Empfehlung, das auf zwei ESP's zu verteilen.
Das mit ROLLO und dem "softwaremäßigen Nachverriegeln" ist nicht optimal, und der Rollladen-Modus in Tasmota selbst ist dem Vernehmen nach super.
Wie dem auch sei: Die Rückfrage aus dem attrTemplate kommt daher, dass bestimmte Inhalte nicht automatisiert ermittelt werden können - hier, weil kein LWT-Eintrag in der readingList in deiner Test-Kopie enthalten gewesen sein dürfte.
Schade, aber keine Option
So ich habe jetzt einen neuen NodeMCU aufgesetzt mit Version 9.1.0
1 Relay an D3 und eins an D6 konfiguriert und angeschlossen
mit SetOption80 1 den ShutterSupport aktiviert
dann mit Shutterrelay1 2
auf
Circuit Safe
First relay: ON/OFF, Second relay: UP/DOWN
umgestellt
dann bekomme ich folgendes Ergebnis
14:32:18 CMD: status 13
14:32:18 RSL: stat/tasmota_9D2E30/STATUS13 = {"StatusSHT":{"SHT0":{"Relay1":2,"Relay2":3,"Open":100,"Close":100,"50perc":50,"Delay":0,"Opt":"0000","Calib":[300,500,700,900,1000],"Mode":"0"}}}
Es wir mit Shutterrelay1 2
SHT0 erstellt der über Relay1 und Relay2 verfügt ? Das andere sind die Angeben zum öffnen schließen und Verzögerung ?
Es gibt ein attrTemplate für den shutter-Modus (genauer: zwei); da ist auch (kurz) erläutert, wie man das kalibriert. Kann aber sein, dass man insgesamt auf bestimmte GPIO-Zuordnungen festgelegt ist, wenn man den Shutter-Modus aktiviert.
Hallo ghostrider,
du solltest noch verraten, wie die beiden Taster/Schalter angeschlossen sind. Vermute ich richtig, dass diese völlig unabhängig von der Fhem-Automation direkt auf den Torantrieb gehen?
Wenn dem so ist, dann brauchst du dich nur um deine 2 Relais und den Sensor zu kümmern. Sowas ähnliches (aber mit der "1-Knopfbedienung") habe ich bei mir realisiert, zusätzlich noch mit einem induktiven Näherungssensor, alles auf einem ESP, und einen völlig unabhängigen Vororttaster + Schlüsselschalter. Ich sehe deshalb bei dir noch keine Not für einen 2. ESP.
Ich nutze einen MQTT-Broker auf meinem Server und in Fhem MQTT-DEVICE (nicht ...2), also old school und etwas zu Fuß ohne Templates. Gründe, warum ich in Fhem noch nicht umgestiegen bin: a) ich kenne mich damit aus und b) es läuft alles, was ich möchte.
Prinzipiell gilt, je besser du beschreibst, was du vorhast, wie du was verbaut und verdrahtest hast, um so präziser können dir kundige Leute helfen.
Viele Grüße Gisbert
@Gisbert: Der Vorschlag mit dem 2. ESP war schlicht der Tatsache geschuldet, dass der TE offenkundig keinen Schimmer hat, wie er eine firmware selbst bauen könnte. Es gibt dazu auch einen firmware-Builder für Tasmota etc pp.; den betreffenden Hinweis auf "selber compilieren" hat der TE aber geflissentlich ignoriert...
Wer weiß, was er tut (das sei dir zugestanden), braucht diese ganzen Hilfsmittelchen nicht, kein autocreate via MQTT2_SERVER, kein erleichtertes JSON-Handling über MQTT2_DEVICE und auch kein attrTemplate, aber wer - wie der TE - "lost in space" ist, sollte mAn. halt einfach bei den vorhandenen Standards beiben und dann eben in den sauren Apfel mit der doppelten Hardware beißen und erforderlichenfalls diese Gimmicks nutzen.
(Du solltest einfach mal eine Testinsel für MQTT2_.* bauen, btw. ;) . EDIT: Vielleicht mit meinem kleinen Workshop (https://forum.fhem.de/index.php/topic,116162.msg1104336.html#msg1104336) das ganze mal durchgehen...?)
Hallo Gisbert,
zu deinen Fragen:
Also das Rolltor ist mit 3 Phasen angeschlossen und besitzt eine Schaltbox es ist eine elero box 75 r Dort gibt es eine Klemmleiste an der ich ganz zu Beginn nur die Taster für AUF AB STOP angeschlossen habe.
Dann kam mir der Gedanke die ganze Geschichte auch über FHEM bedienbar zu machen, daher habe ich mir die MS ELV Markiesensteuerung besorgt.
Die vorhandenen Taster habe ich dann an der Markiesensteuerng angeschlossen und die Markiesensteuerung an die elero box 75 r (Torantriebseinheit mit Endschalter etc.) angeklemmt wo quasi vorher die Taster angeschlossen waren.
Jetzt kann ich über die Taster den Befehl zur MS ELV und dann an die elero box 75 r senden das gleiche geht auch über FHEM.
Da aber diese Funkverbindung schlecht funktioniert und ich keinen Status bekomme möchte ich das ganze jetzt ändern und über das NodeMCU und 2 Relais lösen, nettes Extra man kann ja noch beliebige Komponenten mit verbauen wie z.B. dem BMP 280 etc.
Ich möchte das die Taster an den Nodemcu angeschlossen werden, damit ich auch die Änderung des Schaltzustandes mitbekomme und sehen kann ob das Tor hoch oder runter gefahren wurde bzw. wieder Status ist wenn ich nicht zuhause bin.
Ich habe ein FHEM auf einem Raspberrypi laufen inkl. des MQTT2 Servers in FHEM.
Ich hoffe ich habe nichts vergessen was entscheident ist bzw. was du wissen möchtest.
Danke schon mal für deine Mühe
Hallo ghostrider,
ZitatJetzt kann ich über die Taster den Befehl zur MS ELV und dann an die elero box 75 r senden das gleiche geht auch über FHEM.
...
Ich möchte das die Taster an den Nodemcu angeschlossen werden, damit ich auch die Änderung des Schaltzustandes mitbekomme und sehen kann ob das Tor hoch oder runter gefahren wurde bzw. wieder Status ist wenn ich nicht zuhause bin.
Nur damit ich es richtig verstehe:
Die Taster werden per Hand bedient.
MS ELV registriert die händische Tasteraktion und schickt einen Befehl sowohl zum Motor als auch zu Fhem.
Ich würde vom Konzept her wie folgt vorgehen, weil ich auch das schon bei Rollläden umgesetzt habe, Details erkläre ich gerne Schritt-für-Schritt, wenn du mit dem Vorgehen einverstanden bist:
- Die Tasterstellungen werden über einen GPIO abgefragt, in Tasmota muss dafür an einem GPIO ein Switch definiert werden, dazu ist eine Verbindung vom Nodemcu zum Taster und zurück notwendig.
- In Tasmota (ganz ohne Zentrale) wird definiert - per Rules -, was geschehen soll, wenn ein Taster betätigt wird, Vorteil das Tor funktioniert auch noch, wenn dein Fhem die Krätsche macht.
- In Fhem wird ein Device angelegt, welches das Tor ebenfalls rauf- oder runterschalten kann, bei MQTT2 müssen aber andere helfen, vielleicht lerne ich es mit dir zusammen.
Hier wäre ich aber extrem vorsichtig, wenn du nicht absolut sicher bist, was das Tor macht. Ich rate von jeglicher Fernbedienung oder gar Automatisierung ohne Sichtkontakt ab. Du kannst dir jetzt den schlimmsten Unfall ausdenken, der möglich ist mit deinem Tor, es ist nur ein Frage der Zeit, wann er passiert. Du, deine Kinder oder deine Frau willst du nicht unter deinem Tor/Auto/... begraben sehen, nur weil dein Fhem spinnt, oder eher wahrscheinlich, du mit deiner Programmierung knapp daneben lagst.
Ich habe deshalb für mein Garagentor einen Fensterkontakt von Homematic im geschlossenen Zustand (hätte auch was anderes sein können) und einen induktiven Näherungssensor (hängt am ESP) im offenen Zustand verbaut. Damit weiß ich unabhängig davon, was mein ESP gerade so macht, ob das Tor offen, geschlossen oder irgendetwas dazwischen ist. Ich habe natürlich eine Fernbedienung im Auto, aber ansonsten automatisiere ich da gar nichts, außer dass ich sehe, falls doch mal tagsüber oder abends das Tor offen geblieben ist.
Neben den beiden Relais, würde ich mal behaupten, kannst du etliche Sensoren reinhängen und deine Binärdatei selbst kompilieren.
Dazu ist nicht viel notwendig:
1) https://github.com/arendst/Tasmota (https://github.com/arendst/Tasmota)
2) Einen Gitpod-Account oder -Aktivierung
3) Auswahl der Sensoren, die du gerne hättest (in my_user_config.h im Ordner tasmota)
3) Wenn du das hast, dann in der Kommandozeile folgendes eingeben: platformio run -e tasmota
4) Im Ordner .pio/build/tasmota liegt die fertige, individuelle Binärdatei mit Namen firmware.bin
5) Diese Datei kannst du downloaden und auf deine NodeMCU flashen
Viele Grüße Gisbert
Hallo Gisbert,
und damit bist du schon sehr nah am ersten Satz von Beta-User. Etwas "tun" und "das verstehen was ich tue" sind schon zweierlei Stiefel...
und wie du wohl erwähnst, schon etwas "fahrlässig" was er da vor hat....
...aber mal sehen was draus wird...
LG
Papa Romeo
Zitat von: Papa Romeo am 26 November 2020, 23:32:46
Hallo Gisbert,
und damit bist du schon sehr nah am ersten Satz von Beta-User. Etwas "tun" und "das verstehen was ich tue" sind schon zweierlei Stiefel...
und wie du wohl erwähnst, schon etwas "fahrlässig" was er da vor hat....
...aber mal sehen was draus wird...
LG
Papa Romeo
Hallo, was habe ich denn vor ??
Ich möchte das aktuell verbaute auf einen anderen Hardwarestand bringen ?!
ZitatHier wäre ich aber extrem vorsichtig, wenn du nicht absolut sicher bist, was das Tor macht. Ich rate von jeglicher Fernbedienung oder gar Automatisierung ohne Sichtkontakt ab. Du kannst dir jetzt den schlimmsten Unfall ausdenken, der möglich ist mit deinem Tor, es ist nur ein Frage der Zeit, wann er passiert. Du, deine Kinder oder deine Frau willst du nicht unter deinem Tor/Auto/... begraben sehen, nur weil dein Fhem spinnt, oder eher wahrscheinlich, du mit deiner Programmierung knapp daneben lagst.
Ich habe deshalb für mein Garagentor einen Fensterkontakt von Homematic im geschlossenen Zustand (hätte auch was anderes sein können) und einen induktiven Näherungssensor (hängt am ESP) im offenen Zustand verbaut. Damit weiß ich unabhängig davon, was mein ESP gerade so macht, ob das Tor offen, geschlossen oder irgendetwas dazwischen ist. Ich habe natürlich eine Fernbedienung im Auto, aber ansonsten automatisiere ich da gar nichts, außer dass ich sehe, falls doch mal tagsüber oder abends das Tor offen geblieben ist.
Hi,
zur oben genannten Anmerkung:
Es geht darum das ich das Tor öffnen und schließen kann wenn ich nicht da bin, d.h. in meinem Fall nicht ohne Sichtkontakt.
Ich habe öffters Spedition Lieferungen oder Abholungen die mein Nachbar entgegennimmt/rausgibt in diesem Fall bin ich meistens auf Arbeit bzw. einfach nicht da zu diesen Uhrzeiten.
Bisher war es so das er mich kurz angerufen hat und ich konnte dann das Tor öffnen und die Ware konnte in seinem Beisein abgestellt oder entnommen werden.
Also bei Bewegung des Tores hat immer jemand ein Auge darauf.
ZitatMS ELV registriert die händische Tasteraktion und schickt einen Befehl sowohl zum Motor als auch zu Fhem.
Die FS20MS sendet nur den Befehl zum Motor was anderes kann sie hardwaretechnisch nicht.
Kann nur über Funk empfangen oder über Taster
Dein Konzept entspricht genau wie ich es mir vorstelle.
Ich versuche die Punkte abzuarbeiten.
So ich habe es wie folgt versucht:
Da ich an der Stelle 3 3) Wenn du das hast, dann in der Kommandozeile...
nicht weitergekommen bin, habe ich über https://www.gitpod.io/ den TasmoCompiler verwendet und entsprechend Air/gas sensors aktiviert.
Die Datei wurde erstellt und geflasht.
Unter Generic18 kann ich da den Sensor nicht finden
Es gab da i2C SDA und I2C SCL jetzt nicht auffindbar ?
Ich verstehe jetzt langsam garnichts mehr...
Konnte jetzt die Firmware mit my_user_config.h im Ordner tasmota um die Sensorfunktion erweitern
#define USE_BMP // [I2cDriver10] Enable BMP085/BMP180/BMP280/BME280 sensors (I2C addresses 0x76 and 0x77) (+4k4 code)
Ich habe einen 2. Node mit einer alten Firmware dort läuft der Sensor ich kann D1 und D2 frei konfigurieren mit SDA und SCL siehe Bild.
Ich habe einen neuen Node mit der aktuellen Firmware dort kann ich SDA und SCL nicht frei definieren nach einem Neustart ist die Zuordnung immer so wie auf dem Bild. Er zeigt keine Werte auch wenn ich die Jumper-Kabel umstecke so das die Zuordnung wieder passt?! ???
Zitat von: ghostrider am 27 November 2020, 07:08:37
Es geht darum das ich das Tor öffnen und schließen kann wenn ich nicht da bin, d.h. in meinem Fall nicht ohne Sichtkontakt.
.....
Also bei Bewegung des Tores hat immer jemand ein Auge darauf.
..."Fern-Öffnen" ist ja vielleicht noch o.k., aber "Fern-Schließen" und der Spediteuren soll schauen, dass keiner im Verfahrbereich steht...
nee...da hab ich leider jede Menge andere Erfahrungen. Da musst Glück haben, dass er den Schleißen-Taster eventuell noch selber betätigt
und noch mehr Glück, dass er wartet bis das Tor auch geschlossen ist. Und kommt´s auf Grund von irgendwelchen Schäden da zu einem Streitfall
haste ganz, ganz schlechte Karten....Erfahrung spricht für sich...
Aber egal, soll dein Problem sein...
Zitat von: ghostrider am 27 November 2020, 07:08:37
... und entsprechend Air/gas sensors aktiviert.
LG
Papa Romeo
...ich dachte du wolltest Temperatur-Sensoren o.dgl. anschließen...
Zitat
...ich dachte du wolltest Temperatur-Sensoren o.dgl. anschließen...
Ist das nicht die richtige Auswahl ?
Habe jetzt auch nochmal die
http://ota.tasmota.com/tasmota/release-9.1.0/tasmota-sensors.bin
verwendet geht leider nicht
Hallo ghostrider,
da sollte dir Gisbert weiter helfen, ich kenn mich mit den Programmen die er da nutzt nicht aus, da ich mit der Arduino IDE arbeitete und mir die entsprechenden Punkte zum Aktivieren bzw. Dektivieren bestimmter Funktion direkt im Sketch (ino-Datei) raussuche und dann dort bearbeite bevor ich die Datei dann neu kompiliere.
LG
Papa Romeo
PS: in deinem angehängten Bild vermisse ich z.B. auch OneWire (DS18B20)
Ich würd' ja nicht mit der ide arbeiten. Mit tasmotizer flashen, und damit auch den Speicher löschen.sonst bleiben evtl. die eingestellten Werte erhalten.
Dann lassen sich auch wieder die gpios einrichten. Und interlock, pulsetime gehen auch, aber man muss sich auch ein wenig einlesen, da tasmota sehr komplex ist.die befehls- und parameterliste ist ellenlang....
Zitat von: rr725 am 27 November 2020, 16:49:29
... die befehls- und parameterliste ist ellenlang....
..ist immer relativ. Wenn man weiß wo man suchen und wie man Tasmota und die IDE handhaben muss, passt das schon.
Aber wahrscheinlich ist es deswegen nicht für jeden was..... ??? ;) ::) :o ;D ;D
LG
Papa Romeo
>......Tasmota und die IDE handhaben muss, passt das schon.
Ich mein ja nur..... :-)
Ich mag nodemcu, wemos sehr gern und packe da immer tasmota drauf..es gibt nichts was tasmota nicht kann. Zudem noch via http ansprechbar.
Nur......meine Erfahrung mit der ide- es bleibt häufig Müll im speicher nach dem "bespielen"
Tasmotizer löscht vor dem flashen den Speicher und alles funzt einwandfrei. Aber wer die ide mag....zumal man sich da durch die in's wühlen darf. Wer's mag.
Trotzdem sollte man sich durch die Doku wühlen. A) es ist alles beschrieben, b) viele beispiele für jeden verständlich
So isses und so hat irgendwie hat jeder sein "Steckenpferd".
Ich nutze TASMOTA auch nur wenn´s nicht anders geht.
In der Regel schreibe ich meine Sketche selber, denn da weiß ich dann wirklich, dass nur das passiert was ich will.....in der Regel :-\ ;D ;D ;D ;D ;D
Aber kannst mir ja mal den Link zu den Programmen schicken, dann kann ich´s mir bei Gelegenheit mal zu Gemüte führen :) :D
LG
Papa Romeo
Hallo rr725,
Zitates gibt nichts was tasmota nicht kann
Kleiner Widerspruch von meiner Seite. Tasmota kann ganz viele Dinge "von alleine" und hat deshalb und auch in Verbindung mit Relais seine Stärke. Aber wenn man verschiedene Sensoren gleichzeitig an einen ESP hängen will, dann geht es nicht; zumindest ist das mein Stand vor 6-12 Monaten. Im letzteren Fall ist dann ESPEasy geeignet, oder man muss seinen Sketch selbst programmieren.
Hallo ghostrider,
dein Thread wird leicht entführt, aber du machst es zumindest mir nicht einfach.
Mein Angebot: du sagst mir
exakt, welcher Sensor und was sonst noch alles an die NodeMCU dran soll, dann liefere ich dir alle Files und die Vorgehensweise, die du zum Flashen (unter Win10) benötigst. Austausch hier oder per Email, da per PN keine Anhänge geschickt werden können.
Viele Grüße Gisbert
Hallo Gisbert,
Ich habe nodemcu pyflasher verwendet und auch immer wipe Flash vorher angewählt.
Dein Angebot finde ich sehr gut, würde halt auch gerne wissen was ich an welcher Stelle falsch gemacht habe.
Zunächst wollte ich nur 1 Doppelrelais anschließen und einen BMP280
Funktion sollte so sein wie vorher beschrieben.
Derzeit 1. Taster hoch nochmal tasten Stop
2 Taster Runter nochmal tasten Stop
Entlagen Abschaltung hat der Motor selbst integriert.
Toll wäre noch wenn man es auf mehrere Ebenen Fahren könnte.
Denn idR. brauche ich nur eine bestimmte Höhe um mit Auto rein oder raus zu kommen. Wenn ich z.B. mit dem Schlepper rein fahre wäre die kompletten 4 m höhe nötig.
Die Extra Stop Taste an dem 3er Schalter ist nicht unbedingt nötig würde ja noch einen 3. GPIO belegen ?!.
Gibt es noch eine Sinnvolle Anwendung die man integrieren könnte ?!
Hätte noch mal eine Frage in diesem Zusammenhang.
Wie wird an einem Shellly das 230 V Signal welches vom Schalter geschaltet wird auf den Gpio bzw. die Software vom Shelly umgesetzt?
Zitat von: ghostrider am 28 November 2020, 19:13:43
Funktion sollte so sein wie vorher beschrieben.
Derzeit 1. Taster hoch nochmal tasten Stop
2 Taster Runter nochmal tasten Stop
Entlagen Abschaltung hat der Motor selbst integriert.
Toll wäre noch wenn man es auf mehrere Ebenen Fahren könnte.
Ohne mich jetzt in den Vordergrund drängen zu wollen, mein Link von Post#10 würde genau dem entsprechen...wenn es nicht unbedingt TASMOTA sein muß.
Und wenn man statt dem ESP01 einen ESP12 oder WEMOS oder ähnliches verwendet bleiben noch jede Menge GPIO´s für weiter Anwendungen übrig.
EDIT: Ich weiß jetzt nicht genau ob es jetzt Gisbert oder ein anderes Forumsmitglied ist, der diese Schaltung sogar mit TASMOTA in Betrieb hat.
LG
Papa Romeo
Zitat von: ghostrider am 28 November 2020, 19:13:43
Wie wird an einem Shellly das 230 V Signal welches vom Schalter geschaltet wird auf den Gpio bzw. die Software vom Shelly umgesetzt?
...wenn dir damit geholfen ist....bitteschön.... ;) ;D
LG
Papa Romeo
Hallo Papa Romeo,
ZitatEDIT: Ich weiß jetzt nicht genau ob es jetzt Gisbert oder ein anderes Forumsmitglied ist, der diese Schaltung sogar mit TASMOTA in Betrieb hat.
Das war dann wohl ich.
Hallo ghostrider,
zum weiteren Vorgehen: die Sache wird nicht an einem Tag fertig sein, das muss dir klar sein.
Im Anhang findest du die Dateien, um die NodeMCU platt zu machen die Firmware aufzuspielen, die du brauchst (Win10-Rechner).
Schreib mir eine PN, dann kann ich dir weiterhelfen, ggf. geht auch telefonieren, ansonsten schreibe ich mir die Finger wund.
Wenn die Firmware drauf ist und du dich mit der NodeMCU verbinden kannst, dann haben wir den 1. Schritt geschafft.
Hänge dieses Teil an die Stelle, an der es später hin soll, inkl. Kästchen, Hindernissen für Wlan.
Wenn die Verbindungsqualität akzeptabel ist, dann geht es weiter.
Wie? Du machst dir Gedanken, an welche GPIOs deine Hardware angeschlossen werden soll.
Nicht alle GPIOs können für alle Aktionen benutzt werden, aber es gibt ja reichlich bei der NodeMCU.
Also bitte eine Liste:
Schaltplan der beiden Relais - hardwaremäßige Verriegelung ist vermutlich zu bevorzugen, aber du machst die Vorgaben
Relais1: GPIO...
Relais2: GPIO...
Taster1: GPIO...
Taster2: GPIO...
Taster3: GPIO...
BMP280:
SDA GPIO...
SCL GPIO...
@Papa Romeo, wenn du Vorschläge machen willst, dann gerne
Dann kannst du dir schon mal Gedanken für einen Testaufbau machen, da dann Fehler in der Schaltung viel leichter zu erkennen sind. Ich nehme dafür zwei 230V-Glühbirnen (in rot und grün). Du kannst das natürlich auch beim Tor machen, aber ich wette, dass das Tor 30mal runter- und rauffährt bis es passt.
Die Schaltung wird mit sogenannten Rules innerhalb von Tasmota gemacht. Das hat den Vorteil, dass sie auch ohne Zentrale funktioniert.
Was auch noch wichtig zu wissen ist (es wurde nicht explizit gesagt), ob z.B. Relais1 dauernd Strom schaltet, wenn das Tor fährt. D.h. wenn kein Strom mehr geschaltet wird, hält es an. Das vermute ich, aber das musst du erst noch bestätigen. Die üblichen 1-Knopf-Torschalter funktionieren nähmlich anders, da wird nur ein kurzer Impuls (ca. 0.5 Sekunden) benötigt.
Auf Anhieb habe ich aber noch keine Lösung für das Stoppen beim 2. Tastenbefehl, aber es gibt bei den Tasmota Rules dafür etwas: https://tasmota.github.io/docs/Rules/#roller-shutter-push-button-toggle (https://tasmota.github.io/docs/Rules/#roller-shutter-push-button-toggle). Ich muss mich da aber erstmal einlesen.
Viele Grüße Gisbert
Hallo ghostrider,
die besten Pins für den ESP8266 kann man hier (https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/) nachlesen.
Demzufolge sollte die Pinbelegung wie folgt aussehen (s. Screenshot).
Wenn du geflasht hast, hänge deinen BMP280 dran, platziere ihn an seine spätere Position und starte ihn neu.
Die Sensordaten sollten dann automatisch in Tasmota auftauchen. Da ein Pin für SDA und SCL nicht optimal ist, prüfe bitte, ob der ESP8266 nach stromlos machen wieder startet.
Die beiden Relais sollten wie in der Skizze gezeichnet verschaltet werden (Disclaimer: ich bin kein Elektriker, deshalb nur meine Meinung).
Der Vorteil ist, dass jede Richtung durch ein Relais bedient wird, aber trotzdem eine Hardwareverriegelung vorliegt.
Wenn Relais1 in Aktion ist, dann bekommt Relais2 keinen Strom, also kann es keinen Unsinn anstellen.
Relais2 bekommt nur Strom, wenn Relais1 keinen Strom bekommt. Relais(edit: 2) muss nicht zwingend etwas machen, kann dann aber geschaltet werden.
Kein Strom bitte nicht wörtlich nehmen, denn am Mittelpin des Relais1 liegt natürlich immer 230V.
NC und NO bitte überprüfen, die Relais sollten so geschaltet sein, dass bei Nichtbetrieb, die Relais nicht angezogen sind.
Viele Grüße Gisbert
Hallo Gisbert,
irgendwie häufen sich die Probleme mittlerweile.
Ich bin aktuell unterwegs habe mir aber alles mitgenommen für den Testaufbau.
Wenn ich den ESP flashe und versuche ihn ins WLAN zu hängen passiert nichts mehr.
Ich kann ihn im Netzwerk nicht finden.
Es ist ein Speedport, zuhause mit meiner Fritzbox hatte ich das Problem nicht, ich muss erst mal prüfen woran das nun schon wieder liegt :(
Habe auch schon unterschiedliche Firmware geflasht.
Sobald ich die WLAN Kennung eingegeben habe ist das Ding weg ...
Hallo ghostrider,
keine Eile, ich mache dann weiter, wenn du dazu bereit bist.
Nur zum Verständnis, Tasmota meldet sich zunächst als Access Point, mit dem man sich per Mobile, Tablet, Laptop anmeldet.
Meistens (nicht immer) wird man auf eine Seite geführt, auf der man sein eigenes Netwerk (Credentials) eingibt. Wenn die Seite nicht von selbst will, öffnet man in einem Browser die Seite http://192.138168.4.1 (Achtung: nicht hhtps) und kann dann seine Credentials eingeben.
Dannach ist der Access Point des ESPs natürlich weg, denn der ESP ist jetzt in deinem Wlan. Er macht erst wieder einen AP auf, wenn er von seinem bekannten Netz getrennt wurde.
Du musst herausfinden, welche IP-Adresse er hat, dann kannst du dich mit http://192.168.xx.yy verbinden.
Das sollte immer gehen, allerdings hatte ich einmal einen Sonoff Dual, der war zwar flashbar, aber ansonsten keinen Mucks mehr gemacht hat.
Wenn es partout nicht will, dann nimm einen anderen ESP (NodeMCU, Wemos D1 mini, was auch immer).
Viele Grüße Gisbert
Hallo,
habe jetzt Stunden mit Testen verbracht.
Folgendes Phänomen:
Der ESP lässt sich egal mit welcher Firmware geflasht nicht mit dem Speedport verbinden, er bekommt kein Lease vom DHCP, habe jetzt 2 Stück getestet.
Das Teil ist ganz, wenn ich mit meinen Handy einen Hotspot mache und die Daten eingebe verbindet sich der ESP mit meinem Handy einwandfrei.
::) ::)
Also die Teile sind OK aber warum passiert das habe gelesen das es beim reinkopieren der Credentials zu Problemen kommen kann habe auch alles händisch eingetragen keine Besserung wie gesagt habe x mal geflasht jedes mal das gleiche....
Schon mal jemand so was in der Richtung gehabt .....??
...schon mal feste IP versucht ?
LG
Papa Romeo
Hallo ghostrider,
du Armer, ich kenne das aus eigener Erfahrung, dass mit jedem Schritt zur Lösung sich ein neues Problem auftut, welches aber essentiell ist und deswegen nicht umgangen werden kann. Das scheint ein Naturgesetz zu sein.
Positiv ist ja, dass das Flashen und Verbinden zum Handy Hotspot funktioniert.
Die Rules in Tasmota zum Einschalten eines Relais sind für mich vglw. überschaubar einfach, da ich sie so in Betrieb habe. Kompliziert wird es für mich, wenn der Taster zum zweiten Mal gedrückt wird, und das Relais ausgeschaltet werden soll. Es gibt ein Rule-Beispiel, was ich aber noch nicht verstanden habe, ich bleibe aber dran, sobald ich Zeit habe (d.h. nächstes WE).
Viele Grüße Gisbert
Seit 9.x scheint Tasmota nicht mehr auf den "AP-Mode" zurückzufallen, wenn es keine Verbindung aufbauen kann.
Hast du mal versucht, die 2.Verbindung (hat ja vermutlich andere Credentials) zu konfigurieren, während du den ESP via Handy erreichen kannst?
Ansonsten gab es da auch noch den "setze alles zurück"-Befehl (6x Spannungsversorgung wegnehmen, nach dem 6. (oder 7.?) Mal an lassen).
Hallo Beta-User,
anscheinend 6x, wenn man dieser Info glauben darf: https://tasmota.github.io/docs/FAQ/ (https://tasmota.github.io/docs/FAQ/), ich lese es 6x ausschalten, ergo beim 7. Mal anlassen.
ZitatSeit 9.x scheint Tasmota nicht mehr auf den "AP-Mode" zurückzufallen
Das wäre ja ein Grund Tasmota auf den neuestem Stand bei bestehenden Systemen zu bringen. Doch lieber nicht, man weiß ja nicht, was noch alles geändert wurde. Hast du eine Quelle, wo man es nachlesen kann? Man könnte sich ja mal rantasten.
Viele Grüße Gisbert
Moin.
Nix genaues weiß ich nicht, müßte in den Changelogs stehen. Hatte nur am WE das "Problem", dass ich eine Sonoff-ZigBee-Bridge geflasht hatte und mich da bei den Credentials vertippt. Ergo war die Frage: Zurücksetzen oder die Kabel wieder anlöten. Da das mit dem Zurücksetzen einfach zu finden war und geklappt hat, habe ich mich mit weiteren Details nicht belastet. Ob das mit dem "non-AP"-Mode aber nur eine Spezialität von der betreffenden firmware ist, oder von "minimal" oder was auch immer: Keine Ahnung...
Hallo,
bin nun wieder zuhause.
Allerdings wird die Sache hier echt zum Problem.
Habe den Raspberrypi in einen anderen Raum wegen der Sendeleistung gepackt.
Nun lässt sich nicht mehr auf FHEM zugreifen.
Der Raspberrypi startet bekommt auch eine IP aber unter dieser mit der 8083 am Ende wie früher lässt sich nicht zugreifen.
Jemand dazu vielleicht eine Idee bevor ich wild rum probie?
Ich muss sagen in letzter Zeit war das System träge und nach einem Neustart war der Zugriff auch nicht auf Anhieb möglich aber jetzt geht irgendwie garnichts mehr ;(
ZitatDer Raspberrypi startet bekommt auch eine IP aber unter dieser mit der 8083 am Ende wie früher lässt sich nicht zugreifen.
Hallo ghostrider,
2 Gedanken:
a) Warum packst du den RPi nicht an die Stelle, an der er schon funktioniert hat?
b) Meine Fhem-Zentrale hat eine feste IP, da ändert sich nichts.
Viele Grüße Gisbert
Hallo der Standort macht keinen Unterschied:
Weil der Sendebereich von SlowRF nicht ausreicht musste ich ihnen versetzen, wollte alle Weihnachtsbeleuchtung steuern.
Die IP ändert sich nicht, Irgendwie scheint was mit der FHEM Installation zu sein.
Hallo,
habe jetzt mal den Raspberry aktualisiert:
pi@raspberrypi:~ $ service fhem status
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem; generated; vendor preset: enabled)
Active: active (running) since Sat 2020-12-05 19:09:05 CET; 9min ago
Docs: man:systemd-sysv-generator(8)
Process: 337 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─446 perl fhem.pl fhem.cfg
Dec 05 19:08:57 raspberrypi systemd[1]: Starting LSB: FHEM server...
Dec 05 19:08:59 raspberrypi fhem[337]: Starting fhem...
Dec 05 19:09:05 raspberrypi systemd[1]: Started LSB: FHEM server.
pi@raspberrypi:~ $
Sieht doch eigentlich gut aus ?
Kann aber trotzdem nicht drauf zugreifen.
Es ist zwar dein Thread, aber insgesamt ist es nicht glücklich, ein völlig anderes Thema hier dazwischenzuschieben.
Würde einen eigenen Thread empfehlen, und ggf. das hier erst mal durchaerbeiten:https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche, mit einem Teil scheinst du ja schon durch zu sein.
(OT: init.d?!? Evtl. macht es Sinn, mal ein neues OS auf einer neuen Karte aufzuziehen...?)
So, konnte mich heute mal damit beschäftigen und zwar ist es so das FHEM sporadisch scheinbar nicht läuft wenn man den Raspberry einige male neu startet geht es mal und nach dem nächsten Start nicht mehr und z.B. im 5-6 Versuch geht es wieder.
Auf der Kosnole startet er aber jedesmal: Starting LSB: FHEM server...
Hallo,
Ich habe heute ein neues Raspian aufgesetzt
Lite Version auf eine 4 GB Karte alles eingerichtet FHEM installiert und gestartet.
Jetzt habe ich die 8 GB Karte über einen Kartreader angeschlossen und gemountet da ich das Backup wieder einspielen wollte.
Folgendes Problem während des zurück spielens bekomme ich die Meldung das kein Speicher mehr zur Verfügung steht .
Habe nachgeschaut:
Die 4GB Karte ist komplett voll.
Die Backupdatei hat nur 19 MB gepackt woran kann das liegen?
Die Alte 8GB Karte hat 4.xx GB von 8 Belegt inkl. BS ?
Aber ich spiele ja nicht die komplette Karte zurück
Eine 4GB Karte? Wirklich!!?
Das ist ja nicht mal für Buster alleine "empfohlen"...
Warum so "sparsam"?
Wo hast du überhaupt "heutzutage" noch eine 4GB Karte her (gut ich hab auch noch welche bestellt aber nur um dort /boot drauf zu haben / zu der Zeit wo der PI4 noch nicht ohne SD booten konnt [bzw. nur mit "Hack"])...
Also ich nutze 16GB SDs (wenn überhaupt noch SD: Testsysteme da ist das ok)...
Was "sagt" denn:
df -h
Bevor du das Backup einspielst/einspielen willst?
Und: im fhem Backup sind ja auch die ganzen Logs drin...
EDIT:
Zitat
Die Alte 8GB Karte hat 4.xx GB von 8 Belegt inkl. BS ?
Naja: wo soll dann da noch was hin? Buster nimmt sich (glaube ich) etwas mehr für die Boot-Partition und etwas "Luft" braucht so ein OS ja auch noch...
Gruß, Joachim
Hi,
ich habe auf der 8 GB mein normales System und das Backup.
Hatte die 4 GB noch rumliegen und wollte mal eine Test-Installation machen um zu sehen ob FHEM dann überhaupt wieder läuft da ich ja das Problem habe das es nur noch sporadisch läuft bzw. ich mich einloggen kann nach 6-7 neu Starts
df -h
habe ich leider erst nach dem entpacken aufgerufen
Ich will nur sagen: so ein Test ist doch "Murcks" ;)
Warum nicht eine 16GB besorgen und damit "testen" bzw. nach erfolgreichem "Umzug" einfach ein schönes, neues, gut laufendes (hoffentlich) System "behalten"...
Was meinst du mit einloggen: per ssh auf den PI oder in fhem (mit PW-Schutz)?
Gruß, Joachim
Der PI läuft, per SSH kein Problem.
Nur die FHEM instanz ist nicht mehr erreichbar
Die SD ist noch nicht geliefert
Zitat von: ghostrider am 16 Dezember 2020, 11:56:41
Nur die FHEM instanz ist nicht mehr erreichbar
Was steht denn im Log?
Zitat von: ghostrider am 16 Dezember 2020, 11:56:41
Die SD ist noch nicht geliefert
Na dann...
Ich hab immer so 1, 2, 3 zuhause (kost ja "nix" ;) )...
Gruß, Joachim
Hi, wo muss ich da genau nachsehen?
...ist das noch ein ESP8266-Problem...?
Zitat von: Beta-User am 16 Dezember 2020, 12:34:53
...ist das noch ein ESP8266-Problem...?
Vermutlich nicht...
...aber "sein" Thread ;)
Zitat von: ghostrider am 16 Dezember 2020, 12:33:57
Hi, wo muss ich da genau nachsehen?
Naja, "normalerweise": /opt/fhem/log/fhem-2020-12.log
Bzw. halt das aktuellste "dort"...
Oder wenn du wieder drauf kommst eben "rückwirkend" schauen was drin steht während du nicht drauf gekommen bist...
Gruß, Joachim
Ich weiß...
Zitat von: Beta-User am 06 Dezember 2020, 10:03:34
Es ist zwar dein Thread, aber insgesamt ist es nicht glücklich, ein völlig anderes Thema hier dazwischenzuschieben.
Das "Problem" ist doch, dass jeder, der den Thread ggf. irgendwann wiederfindet, mit diesen ganz anderen Themen wenig anfangen kann und dann nicht weiterlesen wird, selbst wenn es dann irgendwann wieder um das eigentliche Thema geht.
Ich bin - jedenfalls bei nicht "gelösten" Themen - nicht willens, Leute zu supporten, die nicht eine gewisse "Grundhygiene" einhalten wollen und daher voraussichtlich aus diesem Thread raus. Aber Tasmota+MQTT2_DEVICE+attrTemplate für Shutter könnt ihr dann ja auch alleine, ist kein Hexenwerk (es sei denn, man stellt sich ungeschickt an).
Hallo Joachim,
so ich habe jetzt rausgefunden das mein FHEM-Backup 191 MB groß ist und entpackt 3,1 GB groß ist erklärt natürlich warum es nicht funktioniert hat.
Anbei habe ich die LOG von 2020.12 die 2020-11 ist 61 MB groß müsste ich woanders ablegen vielleicht erkennst du so schon in der 2020-11 einen Fehler ?!
Zitat von: MadMax-FHEM am 16 Dezember 2020, 12:42:10
Vermutlich nicht...
...aber "sein" Thread ;)
Naja, "normalerweise": /opt/fhem/log/fhem-2020-12.log
Bzw. halt das aktuellste "dort"...
Oder wenn du wieder drauf kommst eben "rückwirkend" schauen was drin steht während du nicht drauf gekommen bist...
Gruß, Joachim
So jetzt gehts
Also ich würde erst mal den initialUsbCheck deaktivieren:
attr initialUsbCheck disable 1
Hast du selber schon mal reingeschaut?
Interessant wäre halt zu wissen wann du mal gestartet hast und NICHT drauf gekommen bist.
Ansonsten sehe ich eben ziemlich viel connect/disconnect von CUL...
Evtl. dauert der Start (durch initialUsbCheck) zu lange und fhem wird daraufhin vom OS? (systemd?) neu gestartet und wieder neu gestartet usw.
Dann kommst du nat. nicht drauf, weil es ja zwar "da" ist aber auch immer wieder "weg" ;)
Mehr kann ich jetzt nicht sehen...
Gruß, Joachim
Also das ich nochmal drauf kam war wohl irgendwie Zufall.
Das mit dem USB Check kann sein da ich den CUL abgezogen habe um jeden HARDWARE Fehler ggf. auszuschließen.
Habe auch die log von 11-2020 hochgeladen das Problem besteht schon länger als Dezember.
Das Pi OS lief aber ohne Probleme kam zumindest immer zuverlässig in die ssh Konsole.
Habe eben auf einem Ubuntu Notebook Fhem installiert und mein Backup eingespielt scheint bisher ohne Probleme zu laufen.
Werde es jetzt einigemale neu starten und beobachten.
Dann wieder den Pi neu installieren und dort das Backup einspielen
Naja, wenn du den CUL abziehst warum disablest du dann nicht auch das IODev?
Hast du jetzt initialUsbCheck disabled?
Sind deine CUL bzw. USB-Dvices by-id eingebunden?
Wenn nicht kann es (wird es) sein, dass fhem auf einer neuen/anderen Plattform nicht läuft/drauf zugreifen kann...
Viel Erfolg, Joachim
Hallo Joachim,
ich habe jetzt neu auf dem raspberry aufgesetzt 1. test funktioniert, nachdem ich das Backup zurückgespielt habe kein Aufruf mehr möglich.
Dann habe ich gesehen das die CPU-Last auf 100% war daraufhin habe ich wie empfohlen den USB Check über die SSh in der Fhem.CFG auskommentiert ?!
Jeztz scheint es wieder einwandfrei zu laufen seit 1 Std. zumindest.
Ist dieser Ansatz so zu empfehlen ? Bzw. kannst du mir erklären warum was passiert ??? Es wurde ja nichts geändert und plötzlich verursacht es so ein Problem ?
Zitat von: ghostrider am 17 Dezember 2020, 14:16:46
Ist dieser Ansatz so zu empfehlen ? Bzw. kannst du mir erklären warum was passiert ??? Es wurde ja nichts geändert und plötzlich verursacht es so ein Problem ?
Welcher Ansatz?
initialUsbCheck disablen?
Warum nicht?
Läuft bei mir IMMER so...
Wenn du deine USB-Gerätschaften bereits definiert hast (am besten per by-id am zweitbesten per by-path am schlechtesten per /dev/ttyUSBx) und weißt wie du ein neues USB-Dingens definieren musst, dann ist initialUsbCheck unnötig bzw. (wie in deinem Fall) kontraproduktiv...
Vermutlich passiert folgendes:
initialUsbCheck prüft alles was an USB steckt durch und versucht herauszufinden "was es ist"...
...bzgl. fhem.
Da geht die CPU schon mal hoch ;)
U.U. dauert das systemd zu lange (oder was auch immer) und dann wird eben neu gestartet (zumindest sieht einiges in deinem Log so aus) und dann eben von vorne usw.
Gruß, Joachim
Zitat von: MadMax-FHEM am 17 Dezember 2020, 14:24:19
Wenn du deine USB-Gerätschaften bereits definiert hast (am besten per by-id am zweitbesten per by-path am schlechtesten per /dev/ttyUSBx) und weißt wie du ein neues USB-Dingens definieren musst, dann ist initialUsbCheck unnötig bzw. (wie in deinem Fall) kontraproduktiv...
Man kann "usb scan" etc. auch jederzeit von der Kommandozeile aus aufrufen (und sollte dann nur die "Nacharbeiten" noch machen, also eindeutige Adressierung UND (!) ggf. Setzen einer HmID, wenn man je noch Homematic mit einem CUL-Device machen wollte...).
Zitat
Vermutlich passiert folgendes:
initialUsbCheck prüft alles was an USB steckt durch und versucht herauszufinden "was es ist"...
Jein. Es prüft zusätzlich auch, was an der seriellen GPIO-Schnittstelle (UART) zu finden ist. Vermutlich dauert es genau deshalb genau nur bei Pi so lange, dass dieser Effekt eintritt ;) . Das Problem ist, dass für jede Schnittstelle dann alle möglichen Typen durchgetestet werden und jedesmal zwischendurch immer mal wieder auch die Baudrate geändert werden muss und dann gewartet, bis das umgesetzt ist...
Ok,
meine Überlegung war nur das es eben ohne Änderung passiert wie z.B. ein neu angeschlossenen Gerät am UsB oder so?
Vielleicht hängt es mit einem Update von Fhem bzw. dem Pi zusammen ?!
Das mit den USB Geräten einrichten muss ich mir ansehen wie ich das ändern kann.
Hatte das damals so aus einem Toutorial übernommen für die Fgem Installation und war froh das es klappte .