I was just thinking, these forums remind me of my earliest days working in startups, when you showed up for an interview and the furniture was clearly from a local thrift shop, the coffee station was a folding table or plywood over two saw horses, and your interview was conducted with all parties in jeans and a t-shirt. In those days, the focus was strictly on the work and bringing something exciting into the market. People of every history and skill were brought together. The CEO worked right next to you and could be seen cleaning the office's only toilet on a Friday night before he went home. And he was there on Saturday, and on Sunday, because we only worked on days ending in "y".

These forums are a refuge. It's a place where technical discussion can lead over corporate policy and the pressure to sanitize and control the view. It's a place where we can take a wide view of the HA market, and not be beholden to one product. We can share success and failure with, and our adulation or bewilderment for, any product in the space. We talk about bugs and needs and challenges. We get work done. We get work done for each other.

This is shaping up to be a really fun community, and I'm excited to be involved. The direction is forward. Onward!

Well, it's July 19th, and as previously advertised, Reactor (Multi-System, aka MSR) has been published at release 1.0.0.

Docker images are on DockerHub, and download package for bare-metal installs is available at https://reactor.toggledbits.com/download/

Those of you with access to the Mantis Bug Tracker for the project, please continue to use it, particularly if you stick with the "latest" docker image tag (which will continue to be updated periodically, as will the bare-metal tarball). Feel free to open issues there on behalf of other users who do not have accounts if it seems appropriate.

@perh UI stuff is big on my mind these days...

Jeeez, he's still ranting. Have any of you ever heard of "confession by projection"?

Edit: It's time to bring the temperature down over there. We all know who we're dealing with. We've made our point. Thank you all who have chimed in on my behalf as well, and offered words of support here. I'm not leaving until he kicks me off. But it's time to let this one die out, cool the temp and let the forum get back to the business of the community. His anger on display won't change anything anyway; the market will sort him out, not me or anyone else here. For myself, I'm getting on with the business of building tools, and if a single-digit percentage of people use my work, I call that a pretty good day.

Just wanted to wish everyone a very Merry Christmas (or Happy Holidays, if that's your preferred salutation, or...?), and also a very happy, healthy and prosperous New Year 2022.

Everyone:

The quality of questions is a common complaint among those of us that provide "support" for things that we build and offer. As evidence of that, I'll direct you to this post over on the Home Assistant community, which apparently itself was inspired by a similar post in the OpenHAB community.

It opens by explaining the obvious: they are volunteers (as am I), the ratio of supported to supporters is high (i.e. there are far more people asking for help than people providing it), everyone's time is valuable, and it's actually disrespectful of people's time to not put up front effort into your questions and structure them in a way that speeds the resolution process along. The common sense of this should be obvious: if you have a problem or question for which you need a fast answer or solution, should you not then give as much information as possible so that the first reply could be the answer, rather than being only the first of what becomes a back-and-forth exchange that could take hours or days to conclude?

So, I am shamelessly plagiarizing the Home Assistant post for my guidelines here, as it is a good summary of both the ubiquitous problem contributors face in these environments, and what is generally needed to make things more manageable and agreeable. I will say, this is a great summary, and it should be applied everywhere you post, not just here. I'm sure everyone here and everywhere reading your posts, not just the contributors, will appreciate it.

Here we go...

Language

I'm opening with this because the Hass post opens with it, but it hasn't been an issue here yet, so simply for the sake of completeness: support here is given in English. Please make your posts in English, if you can. If you can't, please make your post in your preferred language, but start it with a request to the group for a translation; maybe someone can/will help. We'll try web-based translators, too, of course, but technical language is rarely their strong point. This is one of many areas where community help really makes the experience for everyone.

Try Search First

As the product matures and the community becomes increasingly adept with it, it’s increasingly likely that your question has been asked and answered already. If you search the forum, you may find an answer and save yourself a lot of time. It may not be a perfect answer to your question, but it could get you close enough to start.

The forum search here has a tendency to default to "Titles" (as in, search only in post titles), which is a bit restrictive, so remember to expand your search to "Posts," but from there, hopefully, you'll find something useful.

Try to search only for what is the core of your question - the error message text/keywords (without your specific data), component or add-on name, the operation you want to perform, etc.

Try the Documentation

Every version of Reactor has a "Manual" link in the UI's left navigation that will take you to the locally-installed, version-specific documentation. There is also an online version here, but it may document changes and new things that were not available in the version you are using, so be careful there.

Be Up To Date

Before reporting an issue, be on the latest release. If you are not on the latest release, upgrade to it and try again before posting. If you post and are on an earlier release, it's almost guaranteed that the first thing you'll be instructed to do is upgrade to the latest release.

New Topic Guidelines

If you haven't found anything in Search or Documentation, then make a new topic, following these guidelines:

If a search or your casual reading brings you to a topic/post is somehow similar to, but not exactly, your question, it's better to start a new topic and link to the similar in your introduction than it is to post a reply on the topic you found. This is especially true if the topic you found has gone stale and hasn't had a reply in months or years.

A good opening (head) post a new topic will have most, if not all, of the following:

• A concise title;
• Details of runtime environment (Reactor version, platform info);
• If your question is related to a hub/controller, the type of controller and its running software or firmware version information;
• A complete description of your objective;
• A description of your approach/solution/implementation so far (what you did, how it's intended to work), and what isn't meeting expectations;
• Show the work.

Let's look at the details of that:

Title. Having a good topic title is essential. It should summarize your post so that without even opening it people can have a good idea of what it’s about. A good title generally:

• Includes the unique part of the error you’re getting (redact specifics of your system, e.g. device IDs);
• Contains the integration name, condition or action type, etc.;
• Describes the thing you’re having an issue with;
• Is emotionless.

Examples:

• Good: Action runs before delay action completes
• Bad: Timer not working
• Ugly: Problem/Need help
• Good: Hubitat - Not able to perform dimming.set on Zooz switch
• Bad: Can't control Zooz switch
• Ugly: Switch problem

If you’re having a problem writing a good topic title, leave it for last — once you’ve written the whole question, it might be easier to write a summary title for it.

Describe Your Runtime Environment. It doesn't matter if you did it on a post last week, yesterday, or two minutes ago, every post should include a description of your environment, because I don't keep your system configuration in my head, and future readers will need to know. There are too many people and too many details for me to remember those things, anyway. So each post should include:

• What version of Reactor you are using (upper-right corner of UI);
• What OS your Reactor is running on (Ubuntu, Windows, Synology DSM, Raspbian, etc.);
• How you installed/run Reactor: bare metal, Docker, etc.;
• Specifics of any hubs and devices involved (manufacturer, model, software/firmware versionetc.) in the issue.

Example: Reactor 21308-afecb92a; docker on Synology; Hubitat or Ver 21262; Raspian bare-metal (RPi4); Vera 7.32; Fibaro FGZ-712

Describe the objective, not the problem with your implementation. It’s all too easy to fall into the trap of the XY Problem. If you describe your objective first, then others can understand what you’re trying to achieve. Remember, your objective is not a description of how you're implementing your solution, it's a description of the problem you are trying to solve with your implementation.

• Good: I am trying to get an outdoor light to be on from the day after Thanksgiving through the end of the year.
• Bad: I'm trying to figure out a condition to detect the day after the fourth Thursday in a month.
• Ugly: The date condition in the screen shot below doesn't work.
• Approaching Crime: I tried X and it didn't work (and that's the entire substance of the post).

The first description is (much) better not just because it's concise about timing, but also complete: it lays out the entire problem, not just the one part of it that's giving you trouble right now. Often, good solutions will vary based on the full understanding of the objective (imagine trying to help someone solve the problem of getting fresh air into a large space if they didn't bother to tell you they were building a submarine). It is confusing to other readers and frustrating to helpers when you focus on one step, and when that's resolved, you then add "OK, and now it also needs to...". In the worst case, it can make the entire discussion prior useless.

Show Your Work. Think mathematics class in school: you got no credit for having the right answer if you didn't show how you got there. Worse, if you're sure you have the method correct but you got the wrong answer, nobody could see anything to help you figure out why, including yourself. A big part of the completeness of your response is showing what you've done to try to address it:

• Describe (and show) what you’ve tried, and what the problems were;
• Almost every question about rules or reactions needs to have accompanying screen shot(s) showing the rules and/or reactions you've built; if your description says "I made a rule/reaction that does X", you need to show it; if you say "I tried to do X but it didn't work", you need to show what you tried to do, and you need to explain what you expected, what happened, and how that didn't meet your expectations;
• Check the logs, and post log snippets if you find something you think is relevant;
• Link to some other threads that you’ve found, and tried, and explain why they didn’t help you.

If you haven't tried anything because you're not sure where to begin, the best way to learn is to experiment. Embrace failure, because it's a great learning tool. Remember you are playing with switches and lights, not launch codes for nuclear missiles, so aside from getting "that look" from your spouse, errors are unlikely to have serious consequences.

This also seems a good point for me to offer this: I wrote Reactor as a tool for you to use to solve your automation/logic problems, not as a tool for me to use to solve your automation/logic problems. I am going to increasingly leave logic-only posts that don't involve bugs or specific Reactor operational questions to the community for response. Having me answer every question doesn't improve the ability of the group; that needs to change.

Make good screen shots. If you screen shot your entire display and post it, scaling and downsampling will make it unreadable. If you zoom out your window/browser/screen to get everything in one image it will not be readable. Before taking a screen shot, un-maximize your window and reduce it to a reasonable size, and then screen shot just the window, or better still, grab the relevant rectangle where the action is (but remember, context is important, so be wary of over-cropping — a screen shot of a field with an error flag that doesn't include the condition or action type is probably over-cropped). Do not screen-shot code, log snippets, or formatted text like configs — please use fenced code blocks and paste the real code/data/text (see Format Posts Properly below).

Make good log snippets. When posting logs, always post several dozen lines before anything you find relevant, and a few lines after. Context is important. Think crime scene: it's much easier to determine what happened when a witness describes it than it is to show up to find a dead body on the floor and nobody around. All of the events and messages leading up to the entry that drew your attention may contain vital clues about what was going on to get to that condition. It is also often useful to post (in addition) the startup messages for the most recent restart of Reactor. Do not screen-shot log snippets — post the actual text in a fenced code block (see Format Posts Properly below).

Explain Your Work. It is a nightmare to see posts that contain pages of screen shots of rules and reactions, and yet have no explanation of how they are intended to solve the problem. Do not assume that just because we can read every rule and action, we can understand what that means for your system or how you're thinking about the problem and solution. With your screen shots, provide an explanation of what everything does along the way, why things are done the way they are, and what you think they are intended to do.

Format posts properly. The forums are a tool, and like any tool, you should learn to use it properly if you're going to use it frequently. Learn how to format code, inline and blocks, and use the fenced code block formatting for all code and code-like text (config/YAML, JSON, etc.) and log snippets. Improper formatting can hide errors, or make them more difficult to see. Here's a cheat-sheet for Markdown formatting; it's easy to use fenced code block formatting for code blocks and log snippets.

Redact personal information. Please remember, when posting logs or screen shots, to redact any personal information. This includes serial numbers, API keys, email addresses, lat/long of your home, etc. Remember you are posting this stuff into a public forum, to be captured by search engines and Internet archivers. Forever.

Make sense. Don't let your haste to get your question asked overwhelm good communication. Re-read your post and make sure you've addressed all of the above, and that the post is organized and makes sense. In particular, watch your antecedents. I can't tell you how many "I have two switches but when I turn it on the status doesn't change" posts I've had to straighten out before I can even start guessing what the problem is.

Use (keyword) tags. We're all not using enough keyword tags (full disclosure: I didn't even know they were possible in these forums until recently). Tags can help the search a lot. Common tags may be zwave, hass, hubitat, conditions, reactions, expressions, etc. Hubs, device types, condition or action types are all good candidates for tags. Don't use MSR, msr, or reactor as a tag unless you are posting outside of the Multi-Hub Reactor category; it isn't necessary. Everyone understands that the Reactor category contains Reactor topics/posts, and search lets you limit its breadth to specific categories, so the extra tags are just redundant. In this forum's software (NodeBB), you can enter tags in the bottom of the composer when writing/editing your topic/head post.

Don't tag people/leads in the head post. If you are starting a new topic and writing the opening post for it, and you begin it by tagging me (or whoever the lead(s) is(are) for whatever category), it comes across as bad manners and demanding of an answer. I don't know of any forum in which the category moderators aren't subscribed to their categories (I certainly am), so notifications of new topics go out automatically and such tagging is redundant.

Don't DM product questions. If you have a product question or problem, odds are someone else has or will have the same question/problem at some future date, so having the conversation recorded and searchable in the public forum threads is useful (and respectful of the time invested to help you).

Fix your topic head post. If you are asked to revise your head post because it didn't meet the above guidelines, please edit/correct the head post itself, don't post an add-on reply down below in the thread with the additions or corrections. It's important that the head posts in each topic are high quality and meet these guidelines.

Replies and Discussion

Don't non-answer or distract. If someone asks how to do something in a particular way, unless you are certain that it can't possibly be done the way they are asking, don't reply with an answer that doesn't address the method.

It's sometimes the case that when you feel a need to answer with a different method than OP has inquired about, OP's question/post is posing an X-Y Problem, and in this case, it's likely the post title and description are poor (asking about method rather than goal is a clue), so address that first (e.g. "What is it you are actually trying to accomplish?"). Then you'll have a perfect opportunity to point out different methods.

Don't "Me Too". Don't reply to just say "I'm having this problem too." You can do that if you have additional information to offer that may help in isolating a problem; that's always welcome. But if all you're saying is "me too," that's not really useful and doesn't contribute to the discussion/solution.

Don't use a non-contributing reply as a way to start watching a thread. You may find yourself interested in a thread and want to be notified when there are replies. The bad "Facebook way" is to reply "Following..." (or, again, "me too") in the thread, which makes the forums automatically subscribe you to the thread. It clogs the thread with useless replies. The preferred way is to use the "bell" icon button in the topic header to set a watch on the thread.

Tag people in discussion only when it's relevant to call their attention. Personal tagging can and should be used when mentioning others to thank them for earlier thread responses (i.e. when they are already part of the thread discussion), or add them to the discussion as a link perhaps to another thread on a similar issue going on at the same time, etc. But tagging someone to add them should be considered carefully: consider how welcome that call for attention may be, and how they may feel about the relevance of the discussion or their involvement in it.

Don't hijack or wander. Hijacking or thread-jacking is making a reply that takes the thread off topic. Instead, start a new thread and link to the related thread if there is a relevant connection.

Solved It! When your problem is solved, whether you solved it yourself or someone else did, please mark the head post title [SOLVED]. Ideally, also add a link to the end of your head post to the solution post: you can right-click on the date/time of the solution post and choose "Copy Link..." to get the link, and then paste at the end of your head post Solved here: <paste link>. If you solve your own problem, please make your own post describing what you did (and link to that in the head).

DO NOT FLAIL! If I am working with you on troubleshooting/investigation, asking you to try specific things and give me the results, do not start random experiments, change your entire approach to the problem, make changes I didn't direct, delete things, etc. At that point, I am troubleshooting and need you to be my hands and eyes. If I get the impression that you are making a moving target for me to hit, I'll just stop working with you on it. This is such a serious matter for me that repeated instances may affect your future support.

__________________________________

Inspired by this awesome post in the Home Assistant forums, which itself was inspired by this awesome post over in the OpenHAB forums.

Updated 2023-04-03

Everyone, I've had a change in thinking.

As many of you know, I had decided to not build an MSR interface for eZLO's new controllers, for multiple reasons, not the least of which was that I had chosen not to use an eZLO hub in my future HA. I am currently straddling three hubs: Vera, Home Assistant, and Hubitat. I am actually very much enjoying the flexibility this has provided. But these three hubs are enough for the moment, and when the venerable Vera Plus on which my house has operated since 2017 dies, I will likely just move the rest of my ZWave devices to the other hubs and reduce by one.

Another reason for my previous decision was the risk of fluidity/instability in the eZLO APIs. Since this is first generation work, and even now as they approach the three-year mark on development and are still in "beta" with much functionality still incomplete or missing altogether (plugin UI framework?... anyone? anyone?), it stands to reason that, like all projects in this phase in particular, choices are made that need to be revisited. To be fair, Hass and Hubitat are not immune from this either, even as much more mature products with greater market penetration. In any case, I've demurred because of the high perceived risk of change and breakage, and didn't want to put myself (again) on the critical path of my own user base waiting for me to catch up. I accept now, however, that events like this are just part and parcel of the environment in which I've chosen to work. As I said, if it's not eZLO changing something, it's going to be Hass, or something else. I haven't had a breaking change hit from the Hubitat side yet, but it's probably just a matter of time. Just as I seek to improve my work, they must seek to improve theirs.

The upshot is that I've decided to write an eZLO interface, and I've been working on that for a few days and now have a working prototype running. It works with the few devices I have available for it, and there's a lot that's assumed and untested about all the others. Think back to March, when MSR was first released -- the process of going through and stabilizing these interfaces under all the different external conditions, with devices in your environments that I don't, and sometimes cannot, have -- it takes time. Drilling out all of the details of device behaviors and data, and how each hub handles them differently, takes time. But it's going to be a reality. Aside from this, reading the other forums makes me realize just how much this is needed, if only because there appears as yet to be no articulated concrete plan (e.g. words beyond a promise with no date) to support easy migration from a Vera to an eZLO. MSR touts itself as a tool to assist such migrations between hubs. An eZLO interface must exist.

To set expectations: you'll see the first version of this interface in a build in the next couple of weeks. It will be an add-in. Like MSR itself, I will be limiting the initial audience, and those of you that participate in the early use and testing will be asked to provide lots of diagnostics and feedback (so please don't ask/participate if you're not willing and able to put in the time). It's brand new, unfinished work; there will be lots of bugs, and lots of holes, and it's going to take a lot to get them all squashed and filled, respectively.

Based on what I've learned so far from this project, I also want to forewarn you that it may include access to my cloud infrastructure for automatic logging (to make our mutual efforts to examine problems easier and faster), at least during the early stages. At the moment, MSR has no hard Internet-access dependencies, so this is a change for this interface work.

Also, I probably will ultimately be charging a modest monthly or annual subscription for the eZLO interface, which is a change from policy and practice to date. The amount of effort the project has demanded and can demand in future makes it necessary that I consider a business model. I know that gives some pause, but it should also give you confidence that I am thinking of a long-term future. But, those of you who, as of this writing, hold active accounts on the MSR bug tracker and have participated so valuably in the testing and improvement of MSR, are grand-fathered in to a perpetual (personal/non-commercial use) license to MSR and this interface (no fees, at least for what parts are produced by my hand; I cannot control what others may choose to do if/when third party development takes root). I am considering extending that benefit to everyone who has donated to my projects from the start to date; that is, including those who supported Reactor for Vera, without which MSR would never had been born.

I can probably predict from these forums and others who the active eZLO users are going to be, but if you want to work with me on it, please let me know by reply here. I will be relying on you heavily, because I am not going to be a big consumer of the hub, so a lot of the work will require data collected from you and your hub and investigative work on that evidence, rather than first-hand experience and witnessed events in my own environment. But I'm confident it will work, as much gets done this way already, and investing in more and deeper troubleshooting tools is always a good investment.

Thanks to all of you who have supported this project. Onward...

In the background of other work, I've been putting together a build system for the OpenWrt version that Ezlo is using on the Plus. Job done. I can build pretty much any package, which may come in handy some day.

As a test of that, I thought, why not build nodejs... and you know where that leads, right?

It took some doing. There are a lot of dependencies, and the errors you get when the dependencies aren't met correctly can be cryptic and took quite a bit of research and experimentation to resolve... weeks, in fact, over a couple of hours here, a couple there.

But it's done and I now have Reactor running on an Ezlo Plus.

I'm not sure what the long term utility of this might be. Since the new Ezlo philosophy is to upgrade your system automatically on reboots, and so far the upgrades have wiped substantial parts of the file system in my experience, this could be a non-starter as a platform — you wouldn't want your automations to get blown off the machine every time Ezlo upgrades firmware (because you don't know when that's going to be, and Murphy says it will be while you are on vacation with no remote access). But, if there is some place it can be tucked away safely, or if, as probably should be demanded by the user community, updates become elective and user-driven, it actually makes a nice Pi-ish platform to run on.

On to the next skunkworks project...

Just an FYI for everyone, I'll be on holiday from tomorrow March 10 through March 19, and I'm leaving the laptop on the shelf at home for this one. I can answer emails and forum posts, but I won't likely be checking more than once a day, and I won't doing builds or any bug fixing while away. See you all on the other side!

Everyone,

As a side project, building on some deep innards borrowed from Reactor, I have released two new projects (unrelated to Reactor). Both are published on npmjs (for installation via npm), and on GitHub.

1. ezmqtt — a standalone app that acts as a conduit between Ezlo hubs and MQTT. It's published on npmjs.com and on Github.
2. node-red-contrib-ezlo — Node-RED nodes (installable package) for Ezlo hubs. It's published in the Node-RED Nodes Library, at npmjs.com, and on Github

Why? Because choices are a good thing.

There are docker containers available for ezmqtt, but I haven't finished the work there, so they may not be quite ready for prime time; but feel free to test/play if you want.

@kellyjelly32 said in Home Assistant add-on:

After a reboot they are gone. The whole page with global variables is empty.

OK, that's beyond what I would have guessed from your initial description. I interpreted you to mean that their values are not preserved and are being updated when Reactor starts, but this condition you describe is far beyond that and definitely not the way Reactor is intended to work. That suggests to me that the storage data for at least global expressions, and maybe more you haven't yet detected, isn't being written properly. This could be the fault of a corrupted storage file (i.e. the expressions.json file in the storage subfolder), or improperly configured storage entirely (i.e. the bind mount needed isn't properly set up), or the shutdown by Hass, when it is asked to restart the Reactor add-on, shuts it down in some disorderly way to Reactor/nodejs, so it can't write the storage files (i.e. it gets killed rather than signalled to quit, so it can't perform its cleanup and tidy exit function). If it's the last case (bad shutdown), then you'd probably also notice other changed objects (reactions, rules) are not preserving their changes as well.

If the file is corrupt, you would find logged errors that look like this:

 <SingleFileStrategy:ERR> [SingleFileStrategy][SingleFileStrategy#/home/pi/Documents/MSR/storage/expressions.json] error reading /home/pi/Documents/MSR/storage/expressions.json: [SyntaxError] Unexpected token { in JSON at position 1 [-]

Check for these messages at startup, and any time you attempt to navigate to the Expressions page in the UI. You may also see similar messages at shutdown. If there are messages at shutdown, as well as messages for other files in storage, then it suggests that the storage isn't properly configured (issue with the bind mount, or file permissions in the mounted directory, for example). In any case, if the file is corrupt, you can just remove it and restart Reactor (and then rebuild your expressions; if you are handy with JSON, you could try to repair the file).

But yes, in a normally functioning Reactor system, Rules, Reactions, and Expressions that you create should be saved and return after a restart/reboot as they were before the restart/reboot. Something is definitely amiss there, but it could just be a local configuration issue, not an add-on problem (I would assume some of the other folks using the add-on are consumers of global variables and we haven't seen reports like this from others as yet).

Edit: storage volume (disk) full is also a way to get corruption of storage data and/or unsaved changes.

This post needs to be updated/enhanced to meet the posting guidelines.

@kellyjelly32 said in Home Assistant add-on:

"global expressions" are not persistent

Not sure what this means. Can you explain in more detail?

@kellyjelly32 said in Home Assistant add-on:

"global reactions" survive a reboot

Reactions are stateless. There's no need for them to "survive a reboot" because there's nothing to survive. Again, not sure what this means, and detail would be helpful.

MQTTController 23135

• In action payload, force conversion of all data types to string for "raw" output, rather than assuming result of expression is a string (although docs say to do that, it's just too easy to omit, and too easy to change it so the requirement is moot).
• Add parameter: name value form to action payload definition to draw payload value from the named parameter without the need to use an expression (this follows the implementation of action definitions in other Controller instances as well). That is, you can specify, for example, parameter: level instead of using expr: parameters.level (assuming the parameter value requires no scaling or other modifications to be compatible with the device). [docs]

OK. I can address the error message. Best of both worlds.

You can just send it raw, which has the same effect as your (unnecessary) code addition. In fact, you can just send it JSON, too, since a JSON-ified number is just the number as a string, same-same. Alternately, you can also use:

    payload:
      expr: "str(parameters.setpoint)"

MQTTController 23116 is now available for download; it has hsltorgb(hue,sat,lev) and rgbtohsl(r,g,b) functions available in expressions.

@mgvra said in JSON payload in MQTTController entities actions (+ reverse color mapping to RGB):

So it is this implicit parameters object that contains the value (level) to be set.

Yes, parameters will contain the values of any parameters the action requires/defines.

@mgvra said in JSON payload in MQTTController entities actions (+ reverse color mapping to RGB):

In the case of step dimming, is this the notation?
expr: > { "brightness": parameters.step * 255 }

Well, from the look of it, no. I think your device is going to set the brightness to whatever value is in step, not increment or decrement the brightness by that amount. If your device offers another topic to increment or decrement, you will need to use that instead.

If your device doesn't have up/down brightness topics, you need to emulate them by using what we already know about the device. The entity has the current brightness level on it, so emulating step dimming is a matter of doing the math. Here's an example with fixed 10% up/down. The entity object is loaded with the action's subject entity, so we can access the current dimming level using its attribute:

actions:
  dimming:
    up:
      topic: "zigbee2mqtt/%friendly_name%/set"
      payload: 
        type: json
        expr: >
          { "brightness": min(1, entity.attributes.dimming.level + 0.1) * 255 }
    down:
      topic: "zigbee2mqtt/%friendly_name%/set"
      payload: 
        type: json
        expr: >
          { "brightness": max(0, entity.attributes.dimming.level - 0.1) * 255 }

Note that the dimming capability does not have any parameters for the up and down actions.

@mgvra You're on the right track. For an action like dimming.set, where a JSON payload is to be sent, you set the json type as you've done, and then you just need to make sure that the payload value is an object.

actions:
    dimming:
      set:
        topic: "zigbee2mqtt/%friendly_name%/set"
        payload: 
          type: json
          expr: >
            { "brightness": parameters.level * 255 }

That last line evaluates to an expression language object data type containing a single key brightness whose value is the result of the subexpression, which in this case is the parameter value level given to the action scaled up to the device's units (I guessed; do what works here).

The important thing to realize here is that the expression is producing an object, not a string that looks like JSON. The type: json flag will cause MQTTController to convert the object to its JSON representation, whatever that requires.

Don't forget you can set MQTTController's log level to 5 while doing this work to troubleshoot what you are doing and see more clearly what is ultimately being sent.

I do have functions for converting between HS(L), RGB, and XY. Currently they are only available to HubitatController, but I can easily extend them to MQTTController as well. The trick there, however, is that your device's implementation is the same (e.g. for HSL 0° is red, 120° is green, 240° is blue, etc.). There's a de facto standard, but some devices have their own way.

Reactor build 23114

• Conditions: add is NOT TRUE and is NOT FALSE operators. The is NOT TRUE operator (for example) is unlike the is FALSE operator in that, if the tested value is null, the is NOT TRUE operator result would be true, while the is FALSE operator result would be false. This distinction facilitates some tests where it may be desirable to handle null as equivalent to either true or false without having to provide an additional, separate is NULL condition (and possibly an enclosing OR group).
• DynamicGroupController: document group actions; this makes it an official feature (was experimental).
• Engine/Rule: Clean up a misspelled method name.
• InfluxFeed docs: update supported and recommended versions. [doc]
• HubitatController: Tweak reconnect timing decay (allow for longer decay when hub cannot be contacted for an extended period).
• Reactions: Clarify what "Disabled" means in the constraints of a Group action (incl. Repeat...While) of a reaction. It does not disable the actions in the group. The disable flag applies to the constraint conditions only, having the same effect as it would on rule-based triggers and constraints (i.e. it becomes as if the constraint conditions do not exist). [docs] and [docs]
• HassController: Bless Hass to 2023.4.6