I do a mix. I have rule sets for each room. Generally, these manage lighting, and maybe a small number of specific devices in that area. I have functional rule sets for other things like determining house mode (which is really a blend of season, day of week, time of day, and other switches I can throw for when we're having a party or overnight guests). Functional rule sets also cover room- or level-spanning rules. For example, I bring management of all leak detectors to a single utility rule set.

There's no harm in moving things around. Rules in rule sets have unique IDs that are not affected by their parent location, so moving them changes nothing operationally, it's just an organizational tool for the user. Make a structure and evolve it as you find need. You'll settle into something that works for you.

I know I sound like a broken record, but look at the logs. At startup, much is logged, and if there are problems with file permissions (which I suspect), you'll see it mentioned there in some form.

Reactor build 25097

• Expression syntax enhancement: it is now possible to use a variable's value as a key when creating an object on the fly. For example, if the variable cmd contains the word "econo" (presumably derived from configuration or some other dynamic source), it is now possible to create an object { econo: true } by enclosing the key source in square brackets: obj = { [cmd]: true }. For reference, this syntax mimicks JavaScript.
• Fixed a UI crash when bringing up Reactor initially after using the About page bypass.
• OWMWeatherController: implement sys_system.restart, which will cause all locations to be refreshed immediately.
• OWMWeatherController: new config option (boolean) ignore_certs can be set to ignore certificate errors. These seem to pop up occasionally, perhaps because of a misconfiguration in the load balancing at OWM.

As of build 24343, widget deletion is accomplished by dragging the widget to the top navigation bar (only). Dragging to the left margin no longer deletes the widget.

This change was also mentioned in the release notes for build 24343.

@tamorgen Frankly, it looks like you've made an overly simplistic sensor that you're trying to improve on in the rule... you're taking a low-res image of the device and trying to make it back into something higher-res.

I'd just look at the power directly in Reactor:

@tamorgen said in Need help reducing false positive notifications:

Any thoughts? I know I can set up a a condition to monitor the power sensor value, and make sure it is above 3.5 for 5 minutes, but the condition I need is for the power value to go to the standby value of under 2.9 after that condition is met. That's what I'm unclear how to do.

Look at the condition options (for any condition). You'll see the ability to sequence conditions there -- set a condition so it can only go true after another condition has gone true.

Your problem seems simpler to me, though. Maybe I just don't get the full scope from what you wrote, but what you asked for can be done without sequencing.

If you just want to know if the machine is running, make a rule for power >5W (your 3.7W plus some headroom) sustained for at least 5 minutes (see condition options again). If you want to know if the machine is not running, make a rule for (guessing) power < 15W sustained for 5 minutes. I think you'll find these pretty effectively ignore the transitions between cycles and bumps at the controls or door left open (light on) if you get the power values right for your machine's behavior.

Now you have two rules, one to tell you that it appears to be idle, and the other that it appears to be running. We could use one rule, but by using two rules with a gap between the power values, we create additional hysteresis to prevent those false positives. For you rules that need to react to the machine going idle, use a Rule State condition to check your idle rule; for rules that need to react to the machine running, check the running rule.

@tunnus said in MQTT configuration question:

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.

Yes, you are correct on expr -- I missed it. I will amend my prior post.

map_unmatched is not necessary. The default for map is to leave the value unchanged. And actually, the map_default you provided will result in the default being the string "payload.fan", not the value of the expression payload.fan.

If you've posted the four-letter code to stop the About page from being presented when you enter the UI by default, that is throwing an error and causing the lack of time display, as well as a blank page. This was reported to me earlier, is already fixed, but I have deemed it not serious enough to warrant a rushed build.

It's not about the browser or anything else, it's about whether or not you've attempted to bypass the About page. It is unrelated to OP's post about time synchronization.

@gwp1 said in System Configuration Check - time is offset:

the host time doesn't show for me, oddly. Also, when first loading the MSR page after login it's blank until I click on STATUS.

I know about that. Just sit tight, I'll have another build out over the weekend.

Either your host time or your client (browser) system time is off, or both.

On the host system side, make sure you have some kind of time synchronization running and that it can contact its configured time servers.

On the client/browser side, you don't say what platform you are on, but basically, it's the same idea: make sure that a time sync service is running and that it can contact its servers. For Windows, make sure it's configured to "Set time automatically". Windows is also notoriously resistant to syncing the clock -- my system right now says it last sync'd on March 22. Every couple of hours would be preferable. I've linked an article that might help.

Adjust Windows Time Sync Frequency: https://superuser.com/a/821537

Currently, if an HTTP request fails and the request is set up to save the response, the target response variable will be null. Will that not suffice?

First, always look at the logs. I'm 100% certain that "nothing happens" isn't what's in the logs.

It looks like the device has separate targetValue values for the white channels, so you may just need to use those. That means for red, green, and blue, you'll use targetValue for the property with a JSON object, but leave the propertyKey blank. For warm white, you use property targetValue with propertyKey zero (0), and for cold white you'll use propertyKey one (1).

Edit: look at the logs

@tunnus Kudos! I'm guessing you discovered that something like payload[config.cmd] got you where you were going with that (I'm repeating it here for future readers, since you didn't show your final result).

To your next question, first thing: I believe you said you are using local_mqtt_devices.yaml. You'll "modernize" a bit by moving your template to its own file (e.g. daikin.yaml) in config/mqtt_templates/. Within template files in that subdirectory, you can define both custom capabilities and the templates that use them. They are structured more like a package, so you can more easily share them as others here have done.

In this case, though, you probably don't need to define your own capability. While the system-defined capabilities have values for attributes and action parameters, they are not set in stone. The defined values are a reasonable subset that a lot of devices may have in common, but there would be no way for me to know the entire range of values for every device that ever was or will be, so Reactor doesn't enforce them. They are mostly hints to the UI for reasonable values it can display for the user as a starting point. You can use your own values for hvac_blower_unit.set_mode without defining your own capability; it won't be a problem as long as your implementation (template) expects those values and handles them.

You're on the right track replacing the value_sensor capability with hvac_blower_unit. Using your posted config as a guide, it may look something like below. Let's look at the attributes of the capability first:

daikin_command:
  # some config here, redacted in OP's post
    capabilities: [ "hvac_heating_unit", "hvac_blower_unit" ]
    primary_attribute: hvac_heating_unit.setpoint
    events:
      "some-topic-for-status-I-assume":  # topic was redacted in OP's post
        # hvac_heating_unit stuff redacted for clarity/focus on hvac_blower_unit
        "hvac_blower_unit.state":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: 'payload?.fan !== "X"'  # whatever expression you need here.
        "hvac_blower_unit.mode":
          json_payload: true
          if_expr: '! isnull( payload?.fan )'
          expr: payload.fan
          map:
            A: auto
            Q: quiet
            1: low
            2: low-medium
            3: medium
            4: medium-high
            5: high

What I can't tell from your posts is if there's a value for payload.fan that represents fan off. That would be used to drive the state boolean attribute. You may use an expression like expr: payload?.fan !== "X" Assuming X means off, state will be false when the fan is off, and true when it's running at any speed, which is the intent of the attribute. If the fan is always running or you just don't know (i.e. the device doesn't actually report it), you can forego the if_expr and expr and just supply value: true (or perhaps value: null, meaning "I don't know"), which supplies a fixed value for that attribute that never changes.

For hvac_blower_unit.mode, you can see I've mapped the single-character values to strings. This isn't strictly necessary, but it's in keeping with the spirit of Reactor's design goals. Some of the values map to pre-defined values in the capability, and some don't, and that's just fine. It won't bother Reactor at all.

Now on the action side, we need to add:

    actions:
      hvac_blower_unit:
        set_mode:
          topic: "command/%friendly_name%"
          payload:
            type: json
            expr: |
              value = {},
              value.fan =
                ({
                  "auto": "A",
                  "quiet": "Q",
                  "low": 1,
                  "low-medium": 2,
                  "medium": 3,
                  "medium-high": 4,
                  "high": 5
                })[parameters.mode] ?? parameters.mode, value

This defines the set_mode action for the capability, preparing it to send a JSON payload. It first sets up an empty object in the value local variable. It then sets the fan key in the object by mapping any words given in the mode parameter to the action back to their letter equivalent for the device. If the value of the mode parameter doesn't map, it's just passed through as given (so you can still use the one-letter values directly if you don't want to use the words). Finally, the object in value is returned as the expression result (that's the , value bit at the end).

Digging in to that mapping a little more, we're creating a key-value pair object on the fly to use to look the value in parameters.mode. If it matches a key (i.e. left side of a colon), it changes it to the value (the right of the colon). If it matches nothing, the lookup results in null, which is handled by the ?? operator — when given null on its left, it returns the value of the expression on its right (i.e. if the map isn't matched, parameters.mode as given is the result). This is how you can use either the fancy strings or the one-letter values equally.

Hint: for debugging, when you run an action, MQTTController logs the exact topic and full payload being published at INFO level by default.

Finally, if you truly wanted to define your own capability, you could make your own Daikin+MQTT custom version of hvac_blower_unit by putting it in a capabilities section of your template file (this does not work in local_mqtt_devices.yaml, only in files in config/mqtt_templates/:

capabilities:
  x_mqtt_daikin_moredetail:  # moredetail may include device type, model number, interface type, etc.
    attributes:
      speed:
        type: string
        values:
          - A
          - Q
          - 1
          - 2
          - 3
          - 4
          - 5
    actions:
      set_speed:
        arguments:
          speed:
            type: string
            values:
              - A
              - Q
              - 1
              - 2
              - 3
              - 4
              - 5

This section can just precede the templates: section in your file. You would then adjust the capability name, attribute name, and action and parameters names accordingly in the above example to match your custom definition.

When you post snippets, please don't redact in a way that disrupts the structure. For example, you removed the topics from under events, and other data in your template. For future readers, that makes your post confusing and misleading, so other people that may find your post because they're having the same problem won't be able to follow it as easily. It would also be a courtesy to those other readers if you posted the final solution, for example the expression you finally came up with for the first problem solved.

Link to: MQTTController Documentation

Edit: fix missing expr in example for hvac_blower_unit.mode.

I'm in teaching mode here. I've given you the tools you need. I'll give you a little bit more... where you have payload.cmd, it is literally looking for the key named cmd in the payload. You need it to look for the word that is in cmd as given by your device configuration. This is exactly the same as one small part of the modification I gave you.

Go forth and experiment!

Your post doesn't have enough context. Under what section have you placed the x_mqtt_device structure, for example. You're giving us a bunch of bits and pieces that don't line up to anything, so it's impossible to tell if you even have the right structure, let alone if it's going to do anything like what you want to do. If that's a template, show the entire template, because it just looks like a fragment of one.

You also haven't given us any real context for the device itself. What is it? What topics does it send or receive?

From what is discernible, defining an action (set_speed) that isn't defined as part of the native definition of x_mqtt_device isn't really a good idea. What you need to do is use an existing system capability that is close to your device, or perhaps define your own extended capability, but redefining an existing extended capability will only create problems.

As for the cmd part, you're getting close. What you are missing is the context object for cmd, which is config. So you should be using config.cmd to get to the value of the cmd configuration element. But that's not the whole story... you then need to use that value as a key in creating the object. We'd like the expression language to support { [config.cmd]: true } which is similar to JavaScript, but it doesn't (yet -- I'll look into that). But what you can do is this:

  payload:
    type: json
    expr: 'result={}, result[config.cmd]=true, result'

What this expression does is define an empty object in result, then set the key stored in config.cmd to true, and then returns that amended object as the expression result.

Reactor build 25082

NOTE: Bare-metal users, please run npm run deps in your Reactor directory after updating, then restart Reactor. Generally, you should always do this after upgrading to a new build, but for this build in particular, it's necessary.

• Status Tab: fix an error that could cause lost notifications on object changes to some widgets.
• Packages: update some packages and force one dependency to eliminate a warning from node about a deprecated subsystem (not every package has caught up yet).
• Reactor UI: improve cleanup and memory utilization of tabs when switching between them.
• Engine: The isRuleSet() and isRuleEnabled() expression functions now trigger re-evaluation of expressions in which they appear when the subject rule changes state.
• HassController: Bless Hass to 2025.3.4

ZWaveJSController build 25082

This build of ZWaveJSController requires Reactor build 25082 or higher.

BREAKING CHANGE: For RGBW/RGBWW devices, the color_temperature capability is no longer used; white channels will now be mapped to the dimming capability. If you have such devices and use color_temperature attributes and actions, you will need to make appropriate adjustments to your Rules and Reactions.

• Add support for start and stop heal actions (in zwave_network capability).
• Improve connection retry decay computation (use slow initial decay with rapid ramp).
• Improve handling of white channels in RGBW/RGBWW devices. Mapping them to color_temperature seems to be incorrect in most cases, so they are now mapped to dimming. If the device has multiple channels, the white or color channels may be pushed to child entities.
• The zwave_device.set_value action now accepts JSON in the value fields for Z-Wave JS values that support it. Some devices are able to report or set multiple values simultaneously by using a dictionary as the value (aka JSON object with key/value pairs). RGBWW devices, for example, may support the currentColor and targetColor property with a value object like { "warmWhite": 0, "coldWhite": 0, "red": 128, "green": 0, "blue": 240 }.

You will not be able to set these in one action. You will need to set x_zwave_values.Color_Switch_targetColor_0 to 0 in another action to turn the warm white channel off, and likewise x_zwave_values.Color_Switch_targetColor_1 to 0 to turn off the cold white channel. The intensity of these channels can be set by setting other values up to 255.

It should be possible to set x_zwave_values.Color_Switch_targetColor with a JSON string, but that is not currently supported in ZWaveJSController. That would allow you to set everything at once. I will work on it.

What's the node ID of the bulb (node number)?

Thanks for the update. When I read this, I'm reading that Reactor is operating correctly, doing the same thing that ZWaveJS UI is doing when you change the RGB color, you just want an additional function to be able to change both the RGB and white (one or two channels) at the same time?

If that's not correct, bring me up to speed, and also copy and paste the full attributes for a representative entity (there's a button in the entity detail pane to copy all attributes shown).