Da ich keinerlei Erfahrungen mit LOGO habe, kann ich es dir nicht genau sagen. Aber laut ioBroker Forum soll es seit Adapterversion 1.1.1 funktionieren. Siehe hier. Aktuell ist 1.3.11.
Aus den Beiträgen geht auch hervor, dass es mit openHAB auch eine Möglicjkeit geben soll.
Hallo MAO25 und willkommen im Forum.
Zu2:
Es gibt für ioBroker einen Adapter, mit dem man eine S7 anbinden kann. Ich verwende es mit einer S7-300. Es soll damit auch möglich sein, einige LOGO-CPUs anzubinden. Damit würde dir der Weg offen stehen für Visualisierungen und weitere Anbindungen an andere Systeme.
Gruß SeRef
Bad news.
Sry man, so you have to wait.
I don't know why
I had ordered a Pro 1PM on 07.02.22. At the time, the shop indicated availability from 12.01.22. The order confirmation gave me January 20, 2022 as the shipping date.
On January 28, 2022, I was informed that the delivery had arrived and that the products were brand new and had to be tested before delivery. New shipping date was 07.02.22.
Yesterday evening (February 9th, 2022) I got the message that the check found errors that prevent delivery. The reason for the error has been found and its elimination must now be incorporated into production. The Pro 1PM, Pro 2PM and Pro 2 appear to be affected by this.
Since production takes time, availability is not expected until the end of March.
Das es bei den Kanälen ausgegraut ist, kenne ich nur bei den nicht bedienbaren Geräten (z.B. Fensterkontakt). Diese erscheinen aber dennoch in den Räumen.
Bei bedienbaren Kanälen lässt sich die Bedienbarkeit einstellen. Bei bedienbar (Haken gesetzt) erscheinen sie in den Räumen, bei nicht bedienbar (kein Haken) erscheinen sie auch nicht in der Liste.
Bei CUxD-Geräten ist bei mir das Feld in den Kanälen nie ausgegraut und lässt sich ändern. Ich habe noch mal zum Test neue CUxD Geräte vom Typ 40 mit unterschiedlichen Controls erstellt, konnte aber bei allen den Haken in den Kanälen setzen. Auch bei denen, die als Tür-/Fensterkontakt oder Drehgriffkontakt definiert waren.
Ob es nun daran liegt, dass du Rasperrymatic einsetzt und ich PivCCU, kann ich nicht sagen. Ich weiß, dass es Unterschiede gibt, habe aber im Moment keinen Zugriff auf eine Raspberrymatic um zu probieren, ob es in diesem Fall daran liegen könnte.
Als Nächstes würde ich ein weiteres CUxD Gerät Typ 40 mit Control Schalter erstellen und es damit mal versuchen.
Mach mal einen Haken bei Bedienbar (oberes Bild)
Das scheint die Seite vom Gerät zu sein. Mein Bild stammt vom Kanal.
(Auch) dort kann man den Kanal zu einem Raum hinzufügen. Dann sollte er auch unter Bedienung -> Räume zu finden sein.
Hallo BeTho,
die CUxD Geräte sind wie ein normales Gerät anzusehen. Die dazugehörigen Kanäle sind demnach auch nicht virtuell. Sie lassen sich zu Gewerken und Räumen hinzufügen.
Gruß
SeRef
Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.
Das ist logisch. Verstehe ich denn "Output on URL" falsch? Ich habs so interpretiert, dass der Befehl dann abgesetzt wird, wenn switch=an. Und nicht bei jeder x-beliebigen Aktion. Falsch interpretiert?
Sorry, falsche Info. Bei "Output on URL" natürlich nur beim Einschalten und nicht beim Ausschalten.
Das er allerdings, obwohl schon Ein, auch beim Dimmen den Action auslöst, ist schon fragwürdig. Meiner Meinung nach sollte das nicht so sein und würde es als Bug bezeichnen. Hier wäre es besser, einen separaten Action zu haben, der dann auslöst, wenn der Dimmwert geändert wurde.
Es hat den Anschein, dass alleine das Ändern des Dimmwertes den Action schon auslöst (ob das nun ein Feature oder Bug ist 
)
Wann genau der Action auslöst, ließe sich recht leicht herausfinden. Du könntest z.B. per Befehl eine Variable über die API von ioBroker ansprechen und diese ins Log schreiben lassen.
Bei mir steht immer http?
Solange unter "Output on URL" er per http einen Befehl an sich selber sendet, wird dort http als letzte Quelle stehen, egal auf welchem Weg er ein- oder ausgeschaltet wurde.
Hallo radierer,
ich habe keinen Dimmer um es nachstellen zu können und bin mir über sein Verhalten nicht sicher, habe aber eine Vermutung.
Du schaltest den Dimmer ein. Er sendet daraufhin an sich selbst über Output on (URLs) den Befehl, einzuschalten und auf 50% zu Dimmen. Meine Vermutung ist nun, dass er, da er den Befehl zum Einschalten bekommen hat, wieder den Befehl über Output on (URLs) absendet und so eine Schleife entsteht.
Versuch mal das turn=on wegzulassen:
http://localhost/light/0?brightness=50
Okay, sehe gerade erst, dass es zwar im Forum zum normalen 1PM steht, die Frage aber dem Plus galt. Hatte ich überlesen. 
Wie es sich beim Pro4 PM verhält, kann ich nichts zu sagen. Mein 1PM hinter einer PV zeigt positive Werte und auch die Verbrauchswerte sind positiv. Firmware ist die 1.11.7
Ob Bezug oder Lieferung, die Leistung wird immer als positiver Wert angegeben.
Hallo Schmalz,
Ich habe ein CUX D Typ (40) als Dimmer angelegt.
laut Anleitung sollte es ein Typ(28) sein. Ist an der Seriennummer in der URL für die Actions zu erkennen.
Die Ordnerstruktur ist meines Wissens identisch.
Gruß
SeRef
Wenn es dir nur darum geht, die Variable zu ändern, kannst du dir den Umweg über das CUxD-Gerät sparen. Der Shelly kann die Variable auch direkt ändern:
http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22Anwesend%20Moni%22).State(0)
bzw.
http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22Anwesend%20Moni%22).State(1)
Hallo Wilfrieduc,
Mit x Varianten, eine davon:
http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(“%40NeuCux.CUX4000001:1.SET_STATE%40”).State(1)
In der Url sind die Anführungszeichen (") durch %22 bzw. %27 (') zu ersetzen. Die %40 (@) dürfen dort nicht stehen.
Entweder wird das Gerät über seinen Namen oder über seine Adresse angesprochen. Beides gemischt geht nicht.
http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22NeuCux:1%22).DPByHssDP(%22SET_STATE%22).State(1)
http://user:pw@192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22CUxD.CUX4000001:1.SET_STATE%22).State(1)
Der port 8181 muss enthalten sein. Freigegeben wird er in den Einstellungen zur Firewall. Zum Testen würde ich über den Sicherheitsassistenten die Einstellungen auf Relaxed stellen und wenn es funktioniert wieder zurück auf die alten Einstellungen. Minimiert die Fehlerquellen. In der Url ist dann auch keine Angabe des Nutzers und Passwort nötig.
http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22NeuCux:1%22).DPByHssDP(%22SET_STATE%22).State(1)
http://192.xxx.x.xxx:8181/x.exe?ret=dom.GetObject(%22CUxD.CUX4000001:1.SET_STATE%22).State(1)
Die Url kann zum Testen auch in einem Browser als Adresse eingegeben werden.
Die Befehlszeilen habe ich nicht explizit getestet, sollte so aber passen. Wenn nicht, bitte noch mal melden.
Gruß
SeRef
Aber wird der Wert auch per MQTT mitgeteilt
Ja wird er. Allerdings nicht in kWh, sondern in Wattminuten ohne Kommastelle. Der Wert ist aber bei kleinen Verbräuchen sehr ungenau.
1PM
shellies/shelly1pm-<deviceid>/relay/0/energyreports an incrementing energy counter in Watt-minute
2.5
shellies/shellyswitch25-<deviceid>/roller/0/energyreports amount of energy consumed in Watt-minutebzw.
shellies/shellyswitch25-<deviceid>/relay/<i>/energyfor each relay<i>; reports amount of energy consumed in Watt-minute
In der Tat, das sieht okay aus.
Als Option hättest du den schon erwähnten Tausch des Shelly gegen einen anderen. Damit könntest du den Fehler noch etwas weiter eingrenzen. Kommt es vom Shelly oder eventuell Motor.
Im Firmware Archiv hier im Forum ist v1.9.6 (sollte neu genug ein) und im Filebase die 1.10.4 20210429-102101/v1.10.4-g3f94cd7.
