Beiträge von Athlon

Update - jetzt läuft es:

Netz 1: Shelly Geräte

Netz 2: openHAB 3.2.0 als Docker-Instanz auf einem Raspberry Pi 4

FW-Freischaltungen:

- Netz 1 --> Raspberry Pi 4 aktiv

- Netz 2 --> Netz 1 aktiv

Ausschnitt docker-compose.yml:

services:
  openhab:
    image: openhab/openhab:3.2.0
    container_name: OpenHAB
    network_mode: host
    volumes:
      - '/etc/localtime:/etc/localtime:ro'
      - '/etc/timezone:/etc/timezone:ro'
      - ./openhab_addons:/openhab/addons
      - ./openhab_conf:/openhab/conf
      - ./openhab_userdata:/openhab/userdata
    environment:
      OPENHAB_HTTP_PORT: '8080'
      OPENHAB_HTTPS_PORT: '8443'
      EXTRA_JAVA_OPTS: '-Duser.timezone=Europe/Berlin'
    restart: always

Wichtig:

Im Shelly muss unter "Internet & Security" --> "ADVANCED - DEVELOPER SETTINGS" bei "CoIoT peer" folgendes eingegeben werden: <IPv4-Adresse Raspberry P 4i>:5683. Danach den Shelly neu starten.

Bei installiertem openHAB Shelly-Binding ist im Shelly Manager (https://<IPv4-Adresse Raspberry Pi 4>:8443/shelly/manager/overview) dann in der ERSTEN Spalte "S" der Status sichtbar:

pasted-from-clipboard.png

Als mögliche openHAB-Regel kann man bspw. folgendes nutzen:

rule "PC-Zimmer: Rollladen hochfahren"
when
    Channel "shelly:shelly1pm:<Thing ID>:relay#button" triggered "LONG_PRESSED"
then
    if (PC_Zimmer_Rollladen_POS.state != 100) {
       PC_Zimmer_Rollladen_POS.sendCommand(100)
       logInfo ("PC_Zimmer_Rollladen.rules", "PC-Zimmer: Rollladen hochgefahren (Long push)")
    }
end

Hallo,

ich habe heute meine beiden ersten Dimmer 2 erhalten. *Freu*

Folgendes ist vorhanden:

2x Schalter als Wechselschaltung für 2x "Deckenauslässe", d.h. dort kommen jeweils L, N und Schutzleiter direkt aus der Decke.

Geplant ist folgendes:

Anschluss einer dimmbaren 17 Watt LED-Leuchte inkl. Treiber an je einen Dimmer 2, welcher dann direkt am Deckenauslass angeschlossen wird

Kaum habe ich die Anschlussschemen hier im Forum geöffnet, komme ich schon durcheinander...

Die mitgelieferte Anleitung zeigt vier verschiedene Anschlusssdiagramme - ist hier Diagramm 1 korrekt für meinen Anwendungsfall?

https://shelly.cloud/wp-content/upl…tral_wiring.jpg

Danke für Eure Hilfe!

So, gerade alle 2.5er auf eine neue 1.10er Version aktualisiert über das Webinterface:

20210319-202425/v1.10.0-sw25-g1f21203

Alle Shelly 1PM haben bei mir auch die 1.92 erhalten.

Ich habe den openHAB Container aktualisiert und auch den Shelly 1PM neu eingebunden ohne Eintrag in der .items-Datei. Ich vermute, dass CoAP/CoioT nicht korrekt funktionieren - laut Properties:

coiotAutoEnable false

coiotAutoRefresh false

Die IoT-Geräte befinden sich in einem separaten Netzwerk ("IoT-WLAN"), und openHAB im normalen internen Netz. Ich werde am WE versuchen, IGMP Multicast einzurichten.

Nein, leider erscheint in der events.log nicht alle 5 Minuten ein Update, sondern minütlich:

2020-10-13 22:57:53.389 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_heartBeat changed from 2020-10-13T22:56:53.000+0200 to 2020-10-13T22:57:53.000+0200
2020-10-13 22:57:53.471 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_uptime changed from 2087080 s to 2087140 s
2020-10-13 22:57:53.482 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_meter_lastUpdate changed from 2020-10-13T22:56:53.000+0200 to 2020-10-13T22:57:53.000+0200
2020-10-13 22:58:53.578 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_heartBeat changed from 2020-10-13T22:57:53.000+0200 to 2020-10-13T22:58:53.000+0200
2020-10-13 22:58:53.651 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_uptime changed from 2087140 s to 2087200 s
2020-10-13 22:58:53.663 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_meter_lastUpdate changed from 2020-10-13T22:57:53.000+0200 to 2020-10-13T22:58:53.000+0200
2020-10-13 22:59:53.860 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_heartBeat changed from 2020-10-13T22:58:53.000+0200 to 2020-10-13T22:59:53.000+0200
2020-10-13 22:59:53.939 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_device_uptime changed from 2087200 s to 2087261 s
2020-10-13 22:59:53.955 [vent.ItemStateChangedEvent] - shelly_shelly1pm_bc937d07_meter_lastUpdate changed from 2020-10-13T22:58:53.000+0200 to 2020-10-13T22:59:54.000+0200

Kann es sein, dass ColoT nicht ganz sauber funktioniert? Die Standard Update Interval beträgt 60 Sekunden.

Zitat

Wenn du den Schalter nur einmal kurz drückst siehst du dann einen short_pressed im log ?

Leider nicht.

Update: im openhab.log sehe ich auch nichts...

- Danke, habe Enable Push Events wieder beim 1. Schalter deaktiviert.

- Erkennung über PaperUI inkl. Configuration --> System --> Item Linking --> Simple Mode JA.

Später Einrichtung der für mich relevanten Items/Channels über die .items-Datei inkl. Deaktivierung dieser Channels im PaperUI und (bedingt durch die .items-Einträge) automatische Reaktivierung dieser.

- Ja, die Shellys sind online. Webinterface bzw. Schalten über BasicUI funktioniert einwandfrei (bis auf LONG_PRESSED)

- OpenHab 2.5.9 als Docker-Container

Moin rookie,

auch mit

"shelly:shelly1pm:bc937d07:relay#button"

in der Rule funktioniert es nicht.

Ich habe nun einen 2. Taster in Betrieb genommen. Die jeweiligen OpenHAB Konfigurationsparameter sind wie folgt

1. Schalter (shelly:shelly1pm:bc937d07): Enable Push Events (short/long) JA

Enable ColoT Events JA

2. Schalter (shelly:shelly1pm:1423a7c3): Enable Push Events (short/long) NEIN

Enable ColoT Events JA

Im Shelly Webinterface ist jeweils eine Long Push time von 800 (ms, default) eingestellt.

Wenn ich dort über den Befehl "http://192.168.1.10:8080/basicui/CMD?Ga…schalter=TOGGLE" im Bereich "Actions" --> BUTTON LONG PRESSED URL, funktioniert dieser Aufruf..

Im openhab.log erscheint keine Meldung.

Zitat

rule "Long_Press_Flur" when Channel "shelly:shelly25-relay:c4c4f9:relay1#button" triggered "LONG_PRESSED" then

Hallo, hat es mit dieser Rule geklappt? Ich habe hier einen 1PM und kriege es nicht hin, wenn ich meine ID shelly:shelly1pm:bc937d07:relay#button einfüge...