mqtt2.template: bugs, Fragen, Anregungen

[Martin Fischer]

Stups:

Code Auswählen Erweitern

BASE_TOPIC/([0-9A-F][0-9A-F]\x2e\S{12})/.*:.* "OWFS_$1" oder
 

Code Auswählen Erweitern

BASE_TOPIC/([[:xdigit:]]{2}\x2e\S{12})/.*:.* "OWFS_$1"

ABSOLUT! Was für ein Schnitzer.   Es fehlte tatsächlich ein "Stelle". Ich habe es vollkommen übersehen. Danke!

[Martin Fischer]

Noch eine Frage zum setList in einem Template in Verbindung mit MQTT:
Wenn das Attribut devicetopic gesetzt ist und das Template ein

Code Auswählen Erweitern

attr DEVICE setList \
request:noArg $\DEVICETOPIC/command/REQUEST\
refreshDevices:noArg $\DEVICETOPIC/command/REFRESH_\DEVICES\
refreshValues:noArg $\DEVICETOPIC/command/REFRESH_VALUES
sollte das dann ausreichen, dass der Command published wird? Oder muss da noch irgendetwas bzgl. des IODEV rein?

[Beta-User]

$DEVICETOPIC wird auch in setList aufgelöst, der publish geht dann über das für das Device gültige IO - was auch "falsch" sein kann... Da sollte man aber so oder so prüfen, ob das (Reading) richtig ist und ggf. dann das korrigieren (mAn. via Attribut).

Ansonsten wegen der zwei Zeichen: Hast du jetzt schon mal "heiteres Würfeln mit Perl" ausprobiert oder nicht...?

[87insane]

Hey zusammen,

da ich gerade mein FHEM umziehe, bearbeite ich die ganzen alten Sachen und passe sie an. Dazu gehört auch das Shelly 1 Washer Example. Anbei mal eine Version die ein wenig aufgeräumt ist, mit devStateIcon und event-on.*

Was habe ich angepasst:
- devStateIcon
- devicetopic eingefügt
- event-on-change-reading eingefügt
- event-on-update-reading eingefügt
- readingList $DEVICETOPIC/relay/0/energy:.* energy gelöscht und nur relay_0_kWh übergelassen. $DEVICETOPIC/relay/0/power:.* Werteprüfung eingebaut, da meine Waschmaschine z.B. sonst immer einen 0.x Wert anzeigt obwohl sie aus ist.
- userReadings auf Gegebenheiten angepasst.

Code Auswählen Erweitern

defmod MQTT2_shellyplug_s_040C7E MQTT2_DEVICE shellyplug_s_040C7E
attr MQTT2_shellyplug_s_040C7E devStateIcon { \
my $amp = ReadingsVal($name,"online","false") eq "false" \
? "rot" \
: ReadingsVal($name,"new_fw","false") eq "true" \
? "gelb" \
: "gruen";; \
my $pic = ReadingsVal($name,"loadState","") eq "on"\
? 'scene_laundry_room_fem@red'\
: 'scene_laundry_room_fem';; \
my $text = ReadingsVal($name,"loadState","") eq "on"\
? "Waschmaschine läuft - Aktuell: ".ReadingsVal($name,"relay_0_power","")." W"\
: 'Standby';; \
my $show = "$amp" eq "gelb" \
? "<a href=\"/fhem?cmd.dummy=set $name x_update&XHR=1\">".FW_makeImage("10px-kreis-".$amp)."</a>" \
: "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage("10px-kreis-".$amp)."</a>";;\
"<div> $show <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\"></a>".FW_makeImage($pic)." $text </div>" \
}
attr MQTT2_shellyplug_s_040C7E devicetopic shellies/shellyplug-s-040C7E
attr MQTT2_shellyplug_s_040C7E event-on-change-reading state,online,overtemperature,relay_0_.*,relay0,loadState,wash,price,relay_0_kWh_total
attr MQTT2_shellyplug_s_040C7E event-on-update-reading stat[ERT].*
attr MQTT2_shellyplug_s_040C7E genericDeviceType switch
attr MQTT2_shellyplug_s_040C7E model shelly1_w_energy_measuring
attr MQTT2_shellyplug_s_040C7E readingList $DEVICETOPIC/relay/0:.* {{ state => $EVENT, relay0 => $EVENT}}\
  $DEVICETOPIC/online:.* online\
  shellies/announce:.* { $EVENT =~ m,..id...shellyplug-s-040C7E...mac.*, ? json2nameValue($EVENT) : return }\
  $DEVICETOPIC/announce:.* { json2nameValue($EVENT) }\
  $DEVICETOPIC/relay/0/power:.* {'relay_0_power' => $EVENT > 1 ? $EVENT : '0'}\
  $DEVICETOPIC/relay/0/power:.* { my $compare = $EVTPART0 < 3 ? 'off':'on';; ReadingsVal($NAME,'loadState','off') ne $compare ? { loadState => $compare } : return }\
  $DEVICETOPIC/temperature:.* temperature\
  $DEVICETOPIC/temperature_f:.* {}\
  $DEVICETOPIC/input_event/0:.* { json2nameValue($EVENT) }\
  $DEVICETOPIC/overtemperature:.* overtemperature\
  $DEVICETOPIC/relay/0/energy:.* { relay_0_kWh => sprintf("%.2f",$EVENT/60/1000)}\
  $DEVICETOPIC/longpush/0:.* longpush_0\
  $DEVICETOPIC/info:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplug_s_040C7E setList relay0:on,off,toggle $DEVICETOPIC/relay/0/command $EVTPART1\
  toggle:noArg $DEVICETOPIC/relay/0/command toggle\
  off:noArg $DEVICETOPIC/relay/0/command off\
  on:noArg $DEVICETOPIC/relay/0/command on\
  x_update:noArg $DEVICETOPIC/command update_fw\
  x_mqttcom $DEVICETOPIC/command $EVTPART1
attr MQTT2_shellyplug_s_040C7E setStateList on off toggle
attr MQTT2_shellyplug_s_040C7E userReadings total_temp:loadState:.on { ReadingsNum($name,'relay_0_kWh',0) },\
wash:loadState:.off { ReadingsNum($name,'relay_0_kWh',0) - ReadingsNum($name,'total_temp',0) },\
price:loadState:.off {sprintf("%.2f",ReadingsNum($name,'wash',1)*ReadingsNum('du_kosten','kWhPreis',0))},\
time:loadState:.off {strftime("%H:%M", localtime(ReadingsAge($name,'total_temp',0)-3600))},\
relay_0_kWh_total:relay_0_kWh:.* monotonic {ReadingsNum($name,'relay_0_kWh',0)}
attr MQTT2_shellyplug_s_040C7E webCmd :
ich weiß, @Beta-User du hast gerne fertige Templates. Das mache ich aber noch gesammelt, da ich auch im Bereich Zigbee2mqtt aufräume. Hinzu kommt, dass ich meine alten Gen1 Shellys bis auf die PlugS rauß geschmissen habe und mit den Gen2 Shelly noch einiges testen muss.

Gruß,
87insane

[tomcat.x]

Kann es sein, dass es im "Template hoymiles_opendtu_hub_bridge" einen Bug gibt? Oder ist der mehr in meine Hirn, wegen der mqtt Verwirrungen?

Aber "ac/power" und "dc/power" werden doch beide auf "power" gemapped. Damit hat man immer nur einen der beiden Werte ("dc/power"). Und zwar in dem Fall nicht den, der in der Weboberfläche der openDTU als "Gesamtleitung" angezeigt wird. Dadurch ist es mir aufgefallen. Das gleiche gilt für "is_valid", aber da habe ich noch keine unterschiedlichen Werte gesehen.

Entsprechend dem "hoymiles_opendtu_microinverter" könnte man für "dc/power" "powerdc" nehmen und für "ac/power" "power" lassen.

[Beta-User]

Kann es sein, dass es im "Template hoymiles_opendtu_hub_bridge" einen Bug gibt? Oder ist der mehr in meine Hirn, wegen der mqtt Verwirrungen?

Kann schon sein - das ist vor längerem mal auf die Schnelle entstanden und ggf. schlicht "unfertig" - daher auch das "early version" in der desc..

Du kannst gerne hier (oder im hoymiles-Thread) einen aktualisierten Vorschlag machen, ich mag nur nicht "raten". Die aktuell vercodete readingList für das bub_bridge-Dingens ist nämlich irritierend kurz...

[grizu]

Hallo,

ich hab vor Kurzem gesehen, dass Nuki in ihrer neuen Firmware für das Nuki 3.0 Pro jetzt auch ein Interface per MQTT implementiert hat - damit sollte es möglich sein, dieses Schloss jetzt ohne dedizierte bridge in FHEM einzubinden.
Nach dem Anmelden an den MQTT-Server habe ich folgende Einträge in der reading-List der bridge gefunden (ID durch xxx ersetzt):

Code Auswählen Erweitern

fhemRPI3:nuki/xxx/connected:.* connected
fhemRPI3:nuki/xxx/deviceType:.* deviceType
fhemRPI3:nuki/xxx/name:.* name
fhemRPI3:nuki/xxx/firmware:.* firmware
fhemRPI3:nuki/xxx/serverConnected:.* serverConnected
fhemRPI3:nuki/xxx/state:.* state
fhemRPI3:nuki/xxx/mode:.* mode
fhemRPI3:nuki/xxx/doorsensorState:.* doorsensorState
fhemRPI3:nuki/xxx/batteryCritical:.* batteryCritical
fhemRPI3:nuki/xxx/batteryChargeState:.* batteryChargeState
fhemRPI3:nuki/xxx/batteryCharging:.* batteryCharging
fhemRPI3:nuki/xxx/keypadBatteryCritical:.* keypadBatteryCritical
fhemRPI3:nuki/xxx/doorsensorBatteryCritical:.* doorsensorBatteryCritical
fhemRPI3:nuki/xxx/timestamp:.* timestamp
fhemRPI3:nuki/xxx/lockActionEvent:.* lockActionEvent
fhemRPI3:nuki/xxx/commandResponse:.* commandResponse

nach dem ich die set list dann folgendermassen gesetzt habe:

Code Auswählen Erweitern

lock:noArg nuki/xxx/lockAction 2
unlock:noArg nuki/xxx/lockAction 1
open:noArg nuki/xxx/lockAction 3

hat das eigentlich schon recht gut funktioniert.

Ich bin leider nicht soweit, dass ich selber ein template anlegen könnte, aber vielleicht hat ja ein anderer Interesse.

Die Dokumentation der aktuellen mqtt-Api von Nuki habe ich hier gefunden:
https://developer.nuki.io/t/mqtt-api-specification-v1-4/19223

Grüsse,
Chris

[Beta-User]

Hallo,

ich hab vor Kurzem gesehen, dass Nuki in ihrer neuen Firmware für das Nuki 3.0 Pro jetzt auch ein Interface per MQTT implementiert hat - damit sollte es möglich sein, dieses Schloss jetzt ohne dedizierte bridge in FHEM einzubinden.
[...]

Ich bin leider nicht soweit, dass ich selber ein template anlegen könnte, aber vielleicht hat ja ein anderer Interesse.

Danke auf alle Fälle für's Posten.

Vielleicht kannst du mal auch die Readings bzw. deren Änderung (in einem separaten Thread und selbstredend anonymisiert) posten?

Speziell interessieren würde mich, ob die "state"-Anweisungen dann in der Rückmeldung von der Nuki-Bridge dann auch wieder in state landen oder woanders. In letzterem Fall sollte man das ggf. irgendwie umbiegen....