@toggledbits okay, but the issue now is that, if I upgrade to MQTTController build 25139, I'll get errors which I haven't gotten before

tunnus
Posts
-
Errors after updating to MQTTController build 25139 -
Errors after updating to MQTTController build 25139@toggledbits so if I understood correctly, in the latest MQTTController build it won’t define these kind of attributes automatically which it used to do earlier?
-
Errors after updating to MQTTController build 25139I'm running MSR build 25139 on Docker, using MQTT controller 24293, and everything working as expected. But if I try to upgrade to MQTTController build 25139, I'm getting the following errors on MSR UI:
An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.god Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa auto heating off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.green Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto off" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute temperature_sensor.red Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa filter pump auto run" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.pump Last 11:20:37 An Entity Attribute condition in "Lay-Z-Spa watchdog" (Terrace) failed because the referenced entity "Lay-Z-Spa States" (mqtt>layzspa_states) does not have attribute value_sensor.status Last 11:20:37
My MQTT configuration (local_mqtt_devices.yaml) for the related entity is:
layzspa_message: type: ValueSensor capabilities: ["temperature_sensor", "value_sensor", "power_sensor"] primary_attribute: power_sensor.value events: "layzspa/message": "power_sensor.value": json_payload: true if_expr: '! isnull( payload?.PWR )' expr: "float(payload.PWR)" "value_sensor.air": json_payload: true if_expr: '! isnull( payload?.AIR )' expr: "float(payload.AIR)" "value_sensor.pump": json_payload: true if_expr: '! isnull( payload?.FLT )' expr: "float(payload.FLT)" "value_sensor.god": json_payload: true if_expr: '! isnull( payload?.GOD )' expr: "float(payload.GOD)" "value_sensor.lock": json_payload: true if_expr: '! isnull( payload?.LCK )' expr: "float(payload.LCK)" "value_sensor.unit": json_payload: true if_expr: '! isnull( payload?.UNT )' expr: "float(payload.UNT)" "value_sensor.error": json_payload: true if_expr: '! isnull( payload?.ERR )' expr: "float(payload.ERR)" "temperature_sensor.green": json_payload: true if_expr: '! isnull( payload?.GRN )' expr: "float(payload.GRN)" "temperature_sensor.red": json_payload: true if_expr: '! isnull( payload?.RED )' expr: "float(payload.RED)" "temperature_sensor.target": json_payload: true if_expr: '! isnull( payload?.TGT )' expr: "float(payload.TGT)" "temperature_sensor.value": json_payload: true if_expr: '! isnull( payload?.TMP )' expr: "float(payload.TMP)" "temperature_sensor.virtual": json_payload: true if_expr: '! isnull( payload?.VTM )' expr: "round(float(payload.VTM), 1)" "temperature_sensor.ambient": json_payload: true if_expr: '! isnull( payload?.AMB )' expr: "float(payload.AMB)" "layzspa/Status": "value_sensor.status": if_expr: '! isnull( payload )' expr: "payload" "layzspa/button": "value_sensor.button": if_expr: '! isnull( payload )' expr: "payload"
and in reactor.yaml I have:
"layzspa_states": name: "Lay-Z-Spa States" friendly_name: 'Lay-Z-Spa States' include: layzspa_message
I realize my MQTT configuration might be a bit unorthodox, but could there still be something unintentional in the latest MQTTController build? If needed, I can provide detailed logs.
-
MQTT configuration questionHint: for debugging, when you run an action, MQTTController logs the exact topic and full payload being published at INFO level by default.
I've used MQTTX, which I can highly recommend
-
MQTT configuration question@toggledbits ok, good to know
-
MQTT configuration question@toggledbits thanks again! I did left some stuff out, as I thought they were not relevant for the questions at hand, as I was not trying to present how to configure a particular device, but trying to learn how to do something a bit more "advanced" (and that stuff would be visible to others as well).
Actually only thing I left out from my "daikin_command" template was power_switch:
daikin_command: # also nothing here before capabilities capabilities: [ "hvac_heating_unit", "power_switch", "value_sensor" ] primary_attribute: hvac_heating_unit.setpoint events: "state/%friendly_name%": "power_switch.state": json_payload: true if_expr: '! isnull( payload?.power )' expr: "payload.power ? 'on' : 'off'" ...
For clarity, here's that "payload.cmd" final solution (with some extra logic):
requires: [cmd] events: "state/%friendly_name%": "power_switch.state": json_payload: true expr: 'config.cmd == "swingv" || config.cmd == "swingh" ? payload.swing : payload[config.cmd]'
About "hvac_blower_unit.mode", I think you had forgotten "expr", so I added that, and also "map_default" in case something changes in the other end, and this would continue to work. Also those mapping values were the other way around (something that you could not know).
"hvac_blower_unit.mode": json_payload: true if_expr: '! isnull( payload?.fan )' expr: "payload.fan" map: auto: "Auto" night: "Indoor quiet" low: 1 lowMedium: 2 medium: 3 mediumHigh: 4 high: 5 map_default: payload.fan
-
System Configuration Check - time is offset@Fanan having also the same issue with host time not being visible (build 25082 on Docker), using Chrome browser. With Safari both times are shown.
-
MQTT configuration question@toggledbits ok, got it (took a couple of iterations...)
Then to my original question, now with a little bit more context:
daikin_command: capabilities: [ "hvac_heating_unit", "value_sensor" ] primary_attribute: hvac_heating_unit.setpoint events: "hvac_heating_unit.setpoint": json_payload: true if_expr: '! isnull( payload?.target )' expr: "float(payload.target)" "hvac_heating_unit.units": "°C" "hvac_heating_unit.state": json_payload: true if_expr: '! isnull( payload?.mode )' expr: "lower(payload.mode) == 'heat'" "value_sensor.fan": json_payload: true if_expr: '! isnull( payload?.fan )' expr: "str(payload.fan)" actions: hvac_heating_unit: set_setpoint: topic: "command/%friendly_name%" payload: type: json expr: '{ "temp": min(28, max(16, float(parameters.setpoint))) }' x_mqtt_device: set_speed: arguments: speed: type: str topic: "command/%friendly_name%" payload: type: json expr: '{ "fan": parameters.speed }'
So I want to control fan speed and I noticed there is "hvac_blower_unit" in standard capabilities:
hvac_blower_unit: ... actions: set_mode: arguments: mode: type: string values: - 'off' - auto - continuous - periodic - low - medium - high
But as this wasn't 1:1 capability mapping as compared to my AC unit, I didn't know how to extend/change that to suit my needs. MQTT topics relevant to this case are documented here. Kinda thought using x_mqtt_device was a good idea. Seems to work though.
How can I define my own (extended) MQTT capability? Also, I'd like to utilize those fixed arguments, so something like:
set_speed: arguments: speed: type: str values: - A - Q - 1 - 2 - 3 - 4 - 5
-
MQTT configuration question@toggledbits thanks, cmd part works fine! Other part in the same case is:
... requires: [cmd] events: "state/%friendly_name%": "power_switch.state": json_payload: true if_expr: '! isnull( payload?.cmd )' expr: "bool(payload.cmd) ? 'on' : 'off'"
Again, here "cmd" should translate to "econo", but for this to work I guess something similar you showed could do, but not sure how to formulate that?
-
MQTT configuration questionThen another case, where I'm trying to pass a variable "cmd":
requires: [cmd] ... actions: power_switch: "on": topic: "command/%friendly_name%" payload: type: json expr: '{ "cmd": true }' ...
Expression here seems to be tricky, as "cmd" does not translate to its value (e.g. "econo"). What I'm after here is the following JSON:
{ "econo": true }
I have tried multiple variations, e.g.:
expr: "{ cmd: true }" expr: "{ 'cmd': true }" expr: '{ cmd: true }'
But no luck. The closest I have gotten is with:
expr: '"{" + cmd + ": true }"'
So any help is appreciated!
-
MQTT configuration questionI have the following yaml configuration in local_mqtt_devices file
x_mqtt_device: set_speed: arguments: speed: type: str topic: "command/%friendly_name%" payload: type: json expr: '{ "fan": parameters.speed }'
While this works fine, I'm wondering how this could be changed to "fixed" parameters, as in this case "fan" only accepts "A", "Q" or a numeric value of 1-5?
-
Global expressions not always evaluated@toggledbits great! Will this fix make it to the next build?
-
Global expressions not always evaluatedSimilarly as for local expressions, global expressions evaluate and update fine when getEntity(...) structure is used. However, at least when certain functions are in use, expressions do not update.
Consider the following test case:
Even though auto-evaluation is active, value does not change (it changes only if that expression is manually run). MSR restarts do not help.
Note: Tested using build 25067 on Docker. I have also a PR open (but couldn't now get details or PR number as my Mantis account was somehow expired?).
-
[Solved] Local expression evaluation@toggledbits the main thing is that now I know that this behaviour is not a bug and there's a clear alternative (not using global variables when rule does not trigger often enough).
Anyway, MSR is a great software and thanks for your continued support!
-
[Solved] Local expression evaluation -
[Solved] Local expression evaluation@toggledbits well I guess the following test cases should either prove my point or prove me wrong
Rule 1: (no real triggers, only comments etc)
local expressions:
TempOutside = getEntity( "..." ).attributes.temperature_sensor.value
Rule 2: (no real triggers, only comments etc)
local expressions:
TempOutside = g_TempOutside(where g_TempOutside = getEntity( "..." ).attributes.temperature_sensor.value)
So in my case "Rule 2" -type of local expressions won't be evaluated unless rule is triggered. I'm pretty sure it used to work differently with earlier builds, about a year ago.
-
[Solved] Local expression evaluationContinuing this discussion, I've noticed that if I have local expressions that contain "getEntity(...)" type of variables, these expressions are evaluated every time entity changes. This happens regardless of triggers.
But if I have the same expressions where "getEntity(...)" is replaced by a global variable / expression (and this global variable contains getEntity-structure), these kind of local expressions are not evaluated even if global variable changes. For clarity, expressions would be evaluated if rule is triggered.
@toggledbits, is this behaviour by design? Using build 25060 on Docker.
-
Local notification methods?@toggledbits using a very similar setup and works nicely!
-
Lights switches for warehouseHubitat Elevation is one option (has both z-wave & zigbee)
-
Throttled problem@wmarcolin here's something I've used for a sensor that updates too frequently:
id: virtual4b name: "Lay-Z-Spa temp" capabilities: temperature_sensor: attributes: value: model: time series entity: "mqtt>layzspa_states" attribute: "temperature_sensor.value" interval: 1 # minutes retention: 1 # minutes aggregate: sma precision: 0 primary_attribute: temperature_sensor.value type: ValueSensor
Now I can use this virtual entity instead of a real one in a rule without throttling or logging problems (log files rotating too often etc)