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.

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 or formatted data 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.

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, 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.

OK, the pattern you've written is looking for battery_level at the beginning of the ID. You want the end: /_battery_level$/ and don't include the controller ID for this.

@toggledbits said in Include Entity by Name in Dynamic Group Controller:

Can you show some examples of entity IDs

IDs, not names, please.

@Pabla Your regular expression doesn't seem consistent with the way I've seen Hass assign IDs that contain battery_level. For me, it usually appears at the end. Can you show some examples of entity IDs that you have that you think should match the regular expression you've created, but do not?

Most switches from GE and Leviton these days are three-way compatible/ready, but you need to use the companion switch of the same brand and product family (I think GE even has a package with the two together in the same box).

However, you should not do this yourself. If you are asking here, you do not know what you need to know to do this job safely, and you need to hire a licensed electrician. Practically speaking, wire color means nothing; while there are standards and conventions, there is no telling if your home was wired to those from the start, or if work done since it was built did not alter the original conditions. Nobody here can safely advise you on the current purpose of each of these wires; it would take testing with a meter or other devices to ascertain how the wires are being used, and then, which terminals on the new switch would be connected to which wires on each end. The voltages present here can, and given the opportunity will kill you and/or burn your home down. The electrician would also be able to ascertain if a neutral is present for the new switch, which many require, and many older homes in North America were built without. If that's the case, you may need to find a switch that does not require a neutral (these are available); so consult the electrician before buying any replacement products.

Reactor build 23028

• UI/Rules Editor: Collapsed sections now change the color of the "hidden content" badge -- red if the hidden content contains an error that needs to be corrected before save, green if it contains modified conditions or actions, and info blue (as before) if no errors and unmodified. No badge is shown if the section is empty (as before). The badge icon has been changed to a crossed eye.
• Docs: Add Portainer installation instructions: https://reactor.toggledbits.com/docs/Installation-docker-portainer/
• EzloController: If there are too many consecutive timeouts on requests to the hub, recycle the hub connection.
• HassController: Bless Hass to 2023.1.7

@Edwin1972 I'm wondering why you would upgrade from a very out of date version to an only-slightly-less out of date version?

Current is 23010.

@noelab The wsapi ping timeouts are not related to EzloController. A browser using the Reactor UI is timing out; the browser is at the IP address mentioned. This can happen when the tab or browser go to sleep, the tab is closed, the browser crashes, the device leaves the network (i.e. mobile device leaves the home's WiFi), etc. The connection between the browser and Reactor is a websocket, and the WS protocol requires that periodically, a ping be sent between the client and server so that each know the other is still alive. Usually, you can ignore these messages, but they also can point to network stability problems (see below).

there is no item "rgbcolor" in that rule

The rgbcolor item is the item (an Ezlo term) on the Ezlo device that needs to be modified in response to the command. It is not a Reactor entity attribute, but rather what Reactor's entity attributes maps to on Ezlo's device. In order to change color temperature via the Reactor color_temperature.set action, Reactor has to tell the Ezlo device to change its rgbcolor item.

from the log I saw different kind of error:
[latest-23010]2023-01-20T22:36:30.145Z <EzloController:ERR> EzloController#ezlo request "185d1534ba7" ([Object]{ "method": "hub.item.value.set", "api": "1.0" }) failed: TimedPromise timeout

The time-outs on Ezlo commands are the Ezlo hub's API not acknowledging the command given by Reactor within 15 seconds. There can be several causes for this:

1. Your local network connection to the Ezlo hub is poor and it's dropping packets. If your Ezlo hub is connected to your local network via WiFi, move it to a hard-wired connection. WiFi is often not reliable enough for hub connectivity in home automation. Hubs should always be on hard network connections. If you are already on a hard connection, check your internal network for cabling problems/faults, broadcast storms, or faulty switches/hubs/routers. The fact that you also have wsapi timeouts makes me suspicious that you may have a local network quality problem.
2. Your Ezlo hub is too busy doing something to answer in time. It may be that the Z-Wave mesh is poor and the hub is having problems communicating reliably with the target device, and is thus slow to answer, causing the timeout. Other causes could be a completely different device that is offline/unreachable (out of mesh, battery dead, etc.) causing the hub to be over-busy trying to talk to it, a firmware problem, or a plugin that is overwhelming the system. In any case, EzloController didn't get an answer from the hub within 15 seconds, and that's a hub issue, not something I can address in EzloController.
3. Ezlo firmware bugs. At this point, they've spent about 4-1/2 years since the acquisition of Vera trying to produce firmware and still haven't produced anything that has full functional parity with Vera's last version of firmware. A recent post on their forums by another user observed that "Ezlo is NOT ready for prime time... All these bells and whistles are fine and all, but I STILL - AFTER A YEAR OF WORKING WITH THEM - cannot get a stable system with even a fraction of the devices I have." Another user followed up saying "Their development direction... is confusing and doesn’t show user-centric development." I agree. In my view, their product has not (for too long) and still is not making sufficient, timely progress toward meeting the needs of real users and the quality standard for home automation today. There are better choices with mature, stable products and active, enthusiastic user communities.

Ref: archived post archived post

@tunnus topic logging is separate. Remember that 4MB is 4,194,304 bytes, not 4,000,000. The last message logged before rotation may cause the file to be slightly larger.

Just the way you've done it. I'm still wanting some narrative of what you expected to see vs what is happening, because I think just you thinking about how to write that might have led you to solving your own problem.

I'm pretty sure it's as simple as, you haven't told the configuration what file to send the log to... you need to add a name field in streams for the MQTTController section, so it knows what file name to use for that log stream.

  MQTTController:
    level: 4
    streams:
      - type: file
        name: mqtt.log
        maxsize: 2  
        keep: 2

If you don't want it to log to a separate file, just the regular reactor.log file (i.e. you only want to change MQTTController's log level, not its output destination), then remove the entire streams section from your MQTTController section, so it's just:

  MQTTController:
    level: 4

@tunnus said in MQTT log levels & log rotation:

Trying to set log level for MQTT to the lowest possible, is it in practise level 4?

Four (4) is the default level, which logs information and more severe messages. The severities are critical (0), error (1), warning (2), notice (3), information (4), and debug levels 5 through 9 inclusive.

@tunnus said in MQTT log levels & log rotation:

Also, would like to set maximum size and log rotation, but the following setup in logging.yaml did not work

Good on you for showing the config so, but from the posting guidelines:

... 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