- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
MQTT / Aw: Vebindung zu Zigbee2Mqtt, ...
Letzter Beitrag von Moonlightkid - 23 April 2024, 21:03:08Ach so, okay, danke - hab ich geändert!
Ein Sensor ist mittlerweile als MQTT2_Device sichtbar, dazu noch zigbee bridge und coordinator.
Den Sensor habe ich mit dem Template human-Body-presence-detector versehen. Wie ich meine ist der Wert occupancy true oder false was ich dann zum Schalten benötige.
Fehlen noch die beiden anderen Sensoren. Mal mit dem Laptop herumlaufen und sie wachküssen.
Vielen lieben Dank nochmal für die schnelle Hilfe!
Ein Sensor ist mittlerweile als MQTT2_Device sichtbar, dazu noch zigbee bridge und coordinator.
Den Sensor habe ich mit dem Template human-Body-presence-detector versehen. Wie ich meine ist der Wert occupancy true oder false was ich dann zum Schalten benötige.
Fehlen noch die beiden anderen Sensoren. Mal mit dem Laptop herumlaufen und sie wachküssen.
Vielen lieben Dank nochmal für die schnelle Hilfe!
#2
MQTT / Aw: Vebindung zu Zigbee2Mqtt, ...
Letzter Beitrag von frober - 23 April 2024, 20:49:12 #3
Automatisierung / [ASC] - Merkwürdiges Ventilate...
Letzter Beitrag von Reinhard.M - 23 April 2024, 19:56:44Hallo CoolTux,
ich habe meine Geräte via RAW-Daten von einem Raspi auf einen anderen umgezogen und die Auf/Ab-Steuerung morgens und abends läuft einwandfrei. Auch die manuelle, prozentuale Ansteuerung läuft so wie erwartet. Nicht zu vergessen, natürlich habe ich das ASC Device mit "ScanforShutter" und weiteren Befehlen korrekt eingerichtet. Gleiches gilt für die Devices, die Tag/Nacht Automatik funktioniert ja wie erwartet.
Wenn ich jetzt bei geschlossenem Rollo das Fenster in die "Ventilate" Position bringen, sollte das Rollo in die entsprechende Position hoch fahren. Tatsächlich fährt es aber nur ganz kurz hoch um anschließend runter zu fahren. Das Rollo ist ja geschlossen, damit passiert nichts mehr. Aber in der FHEM Oberfläche zeigt das Device für die Dauer der Fahrzeit "Rollo fährt runter" an. Das Ganze habe ich wie gesagt unverändert von einem Raspi auf einen anderen umgezogen. Vorher lief es einige Jahre ohne Probleme. Hast du eine Idee? Ich füge mal das Listing eines Rollos an, überprüft habe ich es an 2 Rollos.
Gruß Reinhard
ich habe meine Geräte via RAW-Daten von einem Raspi auf einen anderen umgezogen und die Auf/Ab-Steuerung morgens und abends läuft einwandfrei. Auch die manuelle, prozentuale Ansteuerung läuft so wie erwartet. Nicht zu vergessen, natürlich habe ich das ASC Device mit "ScanforShutter" und weiteren Befehlen korrekt eingerichtet. Gleiches gilt für die Devices, die Tag/Nacht Automatik funktioniert ja wie erwartet.
Wenn ich jetzt bei geschlossenem Rollo das Fenster in die "Ventilate" Position bringen, sollte das Rollo in die entsprechende Position hoch fahren. Tatsächlich fährt es aber nur ganz kurz hoch um anschließend runter zu fahren. Das Rollo ist ja geschlossen, damit passiert nichts mehr. Aber in der FHEM Oberfläche zeigt das Device für die Dauer der Fahrzeit "Rollo fährt runter" an. Das Ganze habe ich wie gesagt unverändert von einem Raspi auf einen anderen umgezogen. Vorher lief es einige Jahre ohne Probleme. Hast du eine Idee? Ich füge mal das Listing eines Rollos an, überprüft habe ich es an 2 Rollos.
Gruß Reinhard
Code Auswählen
Internals:
FUUID 66237ab9-f33f-bfa7-3f15-8e6d5ffe675304d8
FVERSION 44_ROLLO.pm:v1.403.0-s18436/2019-01-27
NAME R_Terrasse
NR 60
STATE open
TYPE ROLLO
eventCount 56
stoptime 1713890812
READINGS:
2024-04-20 10:26:13 ASC_Enable on
2024-04-23 06:40:10 ASC_ShadingMessage <html> WARN: global shading active but ASC_Shading_Mode attribut is not set or off </html>
2024-04-23 18:46:52 ASC_ShuttersLastDrive window closed at day
2024-04-23 18:30:12 ASC_Time_DriveDown 23.04.2024 - 20:17
2024-04-23 18:30:12 ASC_Time_DriveUp 24.04.2024 - 06:13
2024-04-23 18:30:09 associatedWith myASControl
2024-04-23 18:46:46 command pct-0
2024-04-23 18:46:46 desired_pct 0
2024-04-23 18:46:46 drive-type modul
2024-04-23 18:46:46 last_drive drive-up
2024-04-23 18:46:52 pct 100
2024-04-23 18:46:52 state open
Attributes:
ASC 2
ASC_AutoAstroModeEvening HORIZON
ASC_AutoAstroModeEveningHorizon -1
ASC_AutoAstroModeMorning HORIZON
ASC_AutoAstroModeMorningHorizon 0
ASC_BlockingTime_afterManual 0
ASC_BlockingTime_beforeDayOpen 0
ASC_BlockingTime_beforeNightClose 0
ASC_BrightnessSensor di_Brightness
ASC_ComfortOpen_Pos 100
ASC_Down astro
ASC_DriveUpMaxDuration 39
ASC_Drive_Delay 0
ASC_Drive_DelayStart 7
ASC_LockOut soft
ASC_LockOut_Cmd blocked
ASC_Mode_Down always
ASC_Mode_Up always
ASC_Open_Pos 100
ASC_Partymode off
ASC_Pos_Reading pct
ASC_Self_Defense_Mode off
ASC_Shading_InOutAzimuth 190:290
ASC_Shading_MinMax_Elevation 10:70
ASC_Shading_Min_OutsideTemperature 21
ASC_Shading_Mode off
ASC_Shading_Pos 24
ASC_Shading_StateChange_SunnyCloudy 60000:30000 3
ASC_Shading_WaitingPeriod 120
ASC_Sleep_Pos 0
ASC_TempSensor MQTT2_WH4000SE:temperature
ASC_Time_Down_Early 16:00
ASC_Time_Down_Late 22:00
ASC_Time_Up_Early 06:00
ASC_Time_Up_Late 08:00
ASC_Time_Up_WE_Holiday 07:30
ASC_Up astro
ASC_Ventilate_Pos 12
ASC_Ventilate_Window_Open on
ASC_WindowRec HM_FK_Terrasse
ASC_WindowRec_PosAfterDayClosed open
ASC_WindowRec_subType threestate
cmdIcon open:fts_shutter_up closed:fts_shutter_down stop:rc_STOP half:fts_shutter_50
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-.:fts_shutter_100:open pct-1.:fts_shutter_90:open pct-2.:fts_shutter_80:open pct-3.:fts_shutter_70:open pct-4.:fts_shutter_60:open pct-5.:fts_shutter_50:closed pct-6.:fts_shutter_40:closed pct-7.:fts_shutter_30:closed pct-8.:fts_shutter_20:closed pct-9.:fts_shutter_10:closed pct-100:fts_shutter_10:closed
gassistantName Terrasse
genericDeviceType blinds
group Alle Rollos
homebridgeMapping {
"OpenClose": {
"reading": "state",
"values": ["/^close/:CLOSED", "/.*/:OPEN"],
"cmdOpen": "open",
"cmdClose": "closed"
},
"TargetPosition": {
"reading": "pct",
"cmd": "pct",
"invert": false
},
"CurrentPosition": {
"reading": "pct",
"invert": false
}
}
realRoom Wohnzimmer
rl_autoStop 1
rl_commandDown set myJaro_Whz down 1
rl_commandStop set myJaro_Whz stop 1
rl_commandUp set myJaro_Whz up 1
rl_excessBottom 2
rl_excessTop 0
rl_forceDrive 1
rl_resetTime 1
rl_secondsDown 31
rl_secondsUp 34
rl_switchTime 1
rl_type HomeKit
room ASC_Rollos,GoogleAssistant
sortby 11
userattr ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforeDayOpen ASC_BlockingTime_beforeNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_CommandTemplate ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_BetweenTheTime ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace,awning,EG_window ASC_SlatPosCmd_SlatDevice ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate
webCmd pct:open:stop:closed
widgetOverride pct:selectnumbers,0,4,100,0,lin
#4
Anfängerfragen / Aw: Fhem abgestürzt
Letzter Beitrag von efyzz - 23 April 2024, 19:33:52Hallo pah,
vielen Dank für die Erläuterung!
Das übersteigt leider meine Kompetenzen bzw. verstehe ich nicht mal, was das genau bedeutet
Ich vermute mal, dass Du mich da auch nicht Schritt für Schritt durchführen willst ...
Aber da ich scheinbar so ziemlich der Einzige mit dem Problem bin, obwohl der Xiaomi-Sauger sicherlich sehr verbreitet ist, reicht vielleicht schon ein Firmware-Update bei meinem Sauger ...? Hab das Ding vor ca. 7 Jahren aus China gekauft, gerootet (um ein deutsches Sprachpaket zu installieren) und seitdem lieber nichts mehr angefasst.
Aber da könnte ich mich mal mit beschäftigen.
Stimmt, FHEM läuft recht schnell wieder. Aber vieles andere auf dem Raspberry nicht mehr, durch den Wechsel des Betriebssystems. Deswegen schrieb ich auch "den Raspberry neu aufsetzen", nicht einfach nur FHEM.
Wenn es Dich wirklich interessiert, hier ein paar Highlights:
https://forum.fhem.de/index.php?topic=19285.msg1302453#msg1302453
https://forum.fhem.de/index.php?topic=135864.msg1293977#msg1293977
https://forum.fhem.de/index.php?topic=136639.msg1299909#msg1299909
Dann noch vieles, vieles mehr, was nicht direkt FHEM betrifft oder ich ohne Hilfe des Forums lösen konnte.
vielen Dank für die Erläuterung!
ZitatAlso erstens den Maintainer von 72_XiaomiDevice antriggern, und zweitens für Crypt::CBC eine Fehlermeldung absetzen.
Das übersteigt leider meine Kompetenzen bzw. verstehe ich nicht mal, was das genau bedeutet
Ich vermute mal, dass Du mich da auch nicht Schritt für Schritt durchführen willst ...
Aber da ich scheinbar so ziemlich der Einzige mit dem Problem bin, obwohl der Xiaomi-Sauger sicherlich sehr verbreitet ist, reicht vielleicht schon ein Firmware-Update bei meinem Sauger ...? Hab das Ding vor ca. 7 Jahren aus China gekauft, gerootet (um ein deutsches Sprachpaket zu installieren) und seitdem lieber nichts mehr angefasst.
Aber da könnte ich mich mal mit beschäftigen.ZitatP.S.: Es würde mich doch interessieren, wie man den Winter damit verbringen kann, ein FHEM-System neu aufzusetzen. Das dauert maximal 30 Minuten, wenn man ein ordentliches Backup hat.
Stimmt, FHEM läuft recht schnell wieder. Aber vieles andere auf dem Raspberry nicht mehr, durch den Wechsel des Betriebssystems. Deswegen schrieb ich auch "den Raspberry neu aufsetzen", nicht einfach nur FHEM.
Wenn es Dich wirklich interessiert, hier ein paar Highlights:
https://forum.fhem.de/index.php?topic=19285.msg1302453#msg1302453
https://forum.fhem.de/index.php?topic=135864.msg1293977#msg1293977
https://forum.fhem.de/index.php?topic=136639.msg1299909#msg1299909
Dann noch vieles, vieles mehr, was nicht direkt FHEM betrifft oder ich ohne Hilfe des Forums lösen konnte.
#5
FHEMapp / Aw: FHEMApp4 - Beta Version
Letzter Beitrag von jemu75 - 23 April 2024, 19:24:14Zitat von: marboj am 23 April 2024, 07:09:46Wenn ein Device-Name zu lang ist, werden, obwohl das Panel aufklappbar ist, auf dem Handy im Hochformat die beiden Pfeile zum aufklappen nicht angezeigt. Im Querformat oder am PC werden sie angezeigt. Nach dem Kürzen des Namens funktioniert es.
Hallo Marco,
Danke für den Hinweis! Ich korrigiere das auf jeden Fall noch.
Grüße
Jens
#6
EnOcean / Aw: Oventrop R-Tronic RT B (od...
Letzter Beitrag von klaus.schauer - 23 April 2024, 19:21:18Nun gibt es eine allgemein gehaltene Rückmeldung der Firma Oventrop zu den verwendeten EEPs und den Verweis auf ein Datenblatt https://www.oventrop.com/Pools/Files/hbtd/de/DE-12101-11507-DB-V2407-OV wibutler Smart Home System - Datenblatt_a35b5c71-37bc-46ab-a5d9-ca43a6d67945.pdf.
Das alles bringt mich aber bezüglich der angeblichen Bidirektionalität des Gerätes nicht weiter. Das Interesse der Hersteller an einer brauchbaren Integration in Fhem war früher erheblich größer. So ändern sich die Zeiten.
Das alles bringt mich aber bezüglich der angeblichen Bidirektionalität des Gerätes nicht weiter. Das Interesse der Hersteller an einer brauchbaren Integration in Fhem war früher erheblich größer. So ändern sich die Zeiten.
#7
Sonstige Systeme / Aw: Entwicklungs-Thread Modul ...
Letzter Beitrag von Starkstrombastler - 23 April 2024, 18:56:26Zitat von: ChristianP5r am 22 April 2024, 13:47:26ich wollte mal nachfragen ob es schon eine neue Version die den Shelly Plus Uni beinhaltet zum testen gibt?Wie versprochen, anbei Version Du darfst diesen Dateianhang nicht ansehen. zum Testen, insbesondere bezüglich der neuen Modelle ShellyPlusUni, ShellyPlusDimmer0-10V und ShellyProDimmer2.
Allerdings ist mir gerade aufgefallen, dass beim ShellyPro3EM nicht alle Readings aktualisiert werden - hier macht das Testen zunächst noch keinen Sinn. (Wer also im großen Stil testen möchte wartet am besten eine verbesserte Version ab).
#8
FHEMapp / Aw: FHEMApp4 - Beta Version
Letzter Beitrag von binford6000 - 23 April 2024, 18:34:49Hi Benni,
und den fhemapp4 Ordner in www und ganz von vorne angefangen. Weiter wie oben zu sehen bin ich nie gekommen.
In der Haupt-FHEM-Instanz hatt ich nie Probleme dieser Art...
VG Sebastian
ZitatVerstehe ich es richtig, dass eine Erstinstallation irgendwann mal über das Modul funktioniert hat?Genau. Ein Update von .37 auf .38 ist mit dem gleichen Fehler fehlgeschlagen. Daraufhin hab ich das gesamte device gelöscht
und den fhemapp4 Ordner in www und ganz von vorne angefangen. Weiter wie oben zu sehen bin ich nie gekommen.
ZitatAnsonsten, hast du das ZIP-File "manuell" auf dem Rechner direkt heruntergeladen? Falls ja, wie und unter welchem User?Ja das hab ich mit dem User seb wie oben zu sehen. Das hat dann anstandslos geklappt.
ZitatMehr fällt mir im Moment leider nicht ein!Wer weiß was das war. Bin mal gespannt wie es dann von beta auf master ausieht.
In der Haupt-FHEM-Instanz hatt ich nie Probleme dieser Art...
VG Sebastian
#9
FHEM Code changes / Revision 28818: 50_Signalbot: ...
Letzter Beitrag von System - 23 April 2024, 18:30:19Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
50_Signalbot: Installer update to signal-cli 0.13.3
Source: Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
50_Signalbot: Installer update to signal-cli 0.13.3
Source: Revision 28818: 50_Signalbot: Installer update to signal-cli 0.13.3
#10
MQTT / zigbee bridge log message even...
Letzter Beitrag von Motivierte linke Hände - 23 April 2024, 18:27:48Hi - Ich habe hier einiges an MQTT Geräten in fhem - viele direkt (Tasmota, Shelly), andere über zigbee2mqtt. zigbee2mqtt habe ich eingebunden, wie im Wiki vorgeschlagen. Das läuft auch gut.
Nur eine Detailfrage habe ich: Ich sehe, dass die MQTT Bridge viele Events (teilweise mehrere pro Sekunde) mit Log-Einträgen produziert, die zu konfigurierten Systemen gehören, wie z.B. (aus dem Event-Monitor kopiert):
Ich weiß, dass ich durch die event-Attribute diese log_message Events abstellen könnte. Ich weiß allerdings nicht, und habe auch in der Commandref nicht gefunden, ob diese Events für die Funktionalität gebraucht werden (z.B. indem das dann umgesetzt wird in Readings für die Devices oder weil es für autocreate benötigt wird oder, oder, oder...).
Ergo: Mache ich was kaputt, wenn ich das Erzeugen von Events für diese log_message Einträge (oder die Bridge insgesamt) abstelle? Ich selbst brauche keine Events von der Bridge, die von den konfigurierten Geräten reichen.
Danke!
Nur eine Detailfrage habe ich: Ich sehe, dass die MQTT Bridge viele Events (teilweise mehrere pro Sekunde) mit Log-Einträgen produziert, die zu konfigurierten Systemen gehören, wie z.B. (aus dem Event-Monitor kopiert):
Code Auswählen
MQTT2_DEVICE MQTT2_zigbee_bridge log_message: MQTT publish: topic 'zigbee2mqtt/Lt_Vorratskeller', payload '{"brightness_relay":254,"linkquality":10,"state":"OFF","state_relay":"OFF"}'Ich weiß, dass ich durch die event-Attribute diese log_message Events abstellen könnte. Ich weiß allerdings nicht, und habe auch in der Commandref nicht gefunden, ob diese Events für die Funktionalität gebraucht werden (z.B. indem das dann umgesetzt wird in Readings für die Devices oder weil es für autocreate benötigt wird oder, oder, oder...).
Ergo: Mache ich was kaputt, wenn ich das Erzeugen von Events für diese log_message Einträge (oder die Bridge insgesamt) abstelle? Ich selbst brauche keine Events von der Bridge, die von den konfigurierten Geräten reichen.
Danke!