@CatmanV2 said in [HowTo] Using HABridge with Reactor:

(PS Cinema was occupied as the cat had just walked in there... )

Actually, what's not there is equally telling. The HTTP request itself probably returned a (failed) result code, so however you made that request, that's the tool that will log that result. The possible HTTP results for that endpoint are:

• 200: The request succeeded, which it did not, because the action itself would have caused more log info that we don't see here;
• 400: The request failed because the action failed. This is not it either, because that is also logged on the Reactor side, and we don't see it here;
• 404: The entity was not found. This isn't logged in Reactor, it's just a fast return.

It's a 404, because you did not give it a canonical ID for the entity in the request URL. A canonical ID includes both the entity ID and it's parent controller's iD — different controllers can have an entity with the same ID, so you have to specify which controller's entity you are targeting. Canoncal IDs take the form controller-id>entity-id (note > between the two parts). The absence of this also explains why the URL encoder didn't make any changes, because that > must be escaped.

So for troubleshooting API calls, remember, if it doesn't work, look at the Reactor log for messages; if nothing is logged on the Reactor side, look at the logs/messages for the tool that made the request to Reactor.

Ref: API docs

Sigh. People, let's make 2026 the year we stop posting one line from the logs. Almost everything we have in the logs requires context. Posting it up-front increases the chances that, if you haven't already figured it out yourself from what's there, someone else can without further back-and-forth in the thread.

Odds are, there's a bunch of interesting stuff following the line you posted, @CatmanV2 that tells how the system is responding to the HTTP request. Let's have a look at it!

Yeah, I think the underlying package has some kind of half-check somewhere, like if (payload) { ... } to see if a payload is being sent, and that would fail for boolean false and other falsy values, but it doesn't matter, I don't assume the proper conversion below me, and I missed it on the exception case in that action, so there's good permanent fix (for the code... my brain, maybe not so much).

All messages and payloads are text. You literally cannot send a boolean as a payload in MQTT. You have to convert all other types to a text representation.

That said, I will look into why MQTTController isn't doing it automatically for this action. It should.

Sorry for the reply delay... I was at a training event for a week.

Edit/Update: found it. The x_mqtt.publish action is handled specially, and that code was missing the default case that would catch and convert non-string/non-object types. The underlying package handles other primitives like Number, but apparently not Booleans. Give me a day or two to settle back in and publish an updated MQTTController.

In the version you are using, it is still required; that's the docs leading the released code by a step (sorry). The version you are using also doesn't enforce limits well, so it allows values that could produce no result, or store more data than needed.

For example, given your retention of 60 and interval of 5, there would be r/i+1 = 13 samples in the series. But if you specify depth of 2, then only the most recent 2d-1 = 3 samples are considered... the other 10 samples don't contribute to the result value. A depth of 7 would be the best match for the given interval and retention (just mathematically, ignoring your semantic goals).

The previous post shows depth as null or not provided. Please specify both depth and retention, restart and wait at least one full interval, then copy-paste the attributes if a value hasn't been calculated.

@tunnus OK. Let's start here: copy-paste the device attributes for that VEC entity (remember to use fenced code block formatting when pasting in reply).

You have to wait for the time series to fill before acceleration can be computed. depth is used in the calculation, as well as retention... that's a peculiarity of this aggregate (accel). There need to be at least 2*depth-1 samples collected before the calculation can occur.

I have updated the documentation in the online version just yesterday, so check here.

@gwp1 said in Reset a delay:

This is where @toggledbits says "wow, that's over-complicated --- try this instead" because he usually does and is usually right LOL. (I tend to overthink/overcomplicate my automations....)

ROFL! Actually, your response is dead-nuts right for both the consequence of @CatmanV2 's approach and what he needs to do to get what he wants. The only critique I have is that the first image is a bit daunting to look at, with all the extra conditions. But overall, as they say: This is the way...

@CatmanV2 foul ball. Not showing your work. Can't guide you properly here. What you are asking is actually default behavior, so either you've done something odd, or there's a bug. Either way, can't tell unless you post your work.

@tunnus Not entirely. I need to spend some time on that. As the post suggested, comment out or remove your retention configuration value. It will be computed from interval and depth.

Simple moving average:

        -
          id: temp_sma
          name: "Outdoor Temperature Average"
          capabilities:
            value_sensor:
              attributes:
                value:
                  model: time series
                  entity: "weather>home"
                  attribute: "wx.temperature"
                  aggregate: sma
                  interval: 60  # minutes
                  depth: 5
                  precision: 2
          primary_attribute: value_sensor.value
          type: ValueSensor

Rate:

        -
          id: garage_humidity_rate
          name: "Garage Humidity Change Rate"
          capabilities:
            value_sensor:
              attributes:
                value:
                  model: time series
                  entity: "mqtt>garage_handt"
                  attribute: "humidity_sensor.value"
                  aggregate: rate
                  interval: 30  # minutes
                  depth: 3  # last three samples, t-0, t-30, t-60
                  precision: 2
                units: "%/min"
          primary_attribute: value_sensor.value
          type: ValueSensor

Have you looked in the logs in /var/log for other messages? Usually there's a good bit more chatter there that can be helpful.

@Pabla said in Single protocol?:

When you make the switch give the new ZWA-2 Z wave antenna a try, it will fix a lot of any lingering problems.

That is exactly where I am headed. Most of the "complicated" devices in my mesh that were on Vera (scene controllers, notably, but also multi-sensors and some devices that were causing issues there) have been moved to a 500-series Z-stick controlled by Z-WaveJS, and I will migrate everything to the ZWA-2 when I get it (on my Christmas wish list, so if it's not under the tree, I'll just gift it to myself after). I have to confess, despite its issues and the horrible ending that Ezlo has given the product (and the tremendous face-in the-dirt failure that their supposed replacement products have been), I remain sentimental. So much wasted potential. Alas, we move on.

Edit: just now, to illustrate:

I'm also in the Z-Wave camp, with about 100 devices in my mesh. I still have some on Vera, so I actually have two Z-Wave networks active in my home. There's no question that Vera was a big contributor to problems with early Z-Wave experience. Even my oldest devices run well under Z-WaveJS. Multi-sensors that needed battery changes monthly on the Vera run for months without a change on Z-WaveJS (I suspect Vera's frequent restarts and "configuration" of each device each time are to blame). With the rapidly-declining stability of Ezlo's Vera cloud infrastructure, especially Alexa issues of late, I'm planning on being entirely off before March 1.

I've definitely had a few Z-Wave devices give up the ghost (or the radio); mostly older devices from lesser manufacturers of the time. The largest single group of switches and dimmers I have are all Leviton and around 11 years old, and I've only had one fail (radio died, otherwise functional). GE/Jasco seems to have held up second best among the high-age devices. Many of the other brands didn't make it two years, and those brands no longer exist, too. Everything I've bought in the last 4-5 years is holding on well. I think Zooz gets the award for most-improved. I didn't think much of them a few years ago (and told them so), but their more recent offerings have been stable and well-supported.

Part of the recent stability may be due to a campaign I went on several years ago (bored during Covid), where I found and fixed a number of small electrical problems in my house resulting in a variety of neutral issues (that is, issues with excessive current on the neutral wire). One of the most egregious was that our clothes dryer had been installed by the delivery guys to our four-wire connection with the neutral and ground bonded inside the dryer -- the bonding wire should have been removed for the four-wire service. This resulted in some fairly high circulating neutral and ground currents throughout the house, and in combination with other problems found (loose neutral or ground wires at receptacles, for example) was potentially hazardous and may have led to the failure of those less-robust devices. As I said, the last few years, I don't recall replacing any devices, so I've either eliminated a source of induced failure, culled out all of the weak, or both. I also have whole-house surge protection on my main panels. When my Internet was cable-carried (it no longer is), I had surge/lighting protection at the entrance.

I'm not enthusiastic about WiFi as an HA protocol for a few reasons: power demand, crowded bands, and user knowledge/security. While I love the simplicity of the Shelly WiFi-based devices and use them without reservation, they do not compare in battery life to even the oldest of my Z-Wave devices (well, those no longer on the Vera). The powered devices are fine. Powering many WiFi devices also seems to be "unevolved" -- Shelly gives you terminal connections for line voltage when powered; most others are USB micro or C at 5V with a wall wart, which truly sucks, and finding small UL-listed power supplies that can (and must be) safely installed in a US single-gang box or other enclosure is a nuisance and would make an insurance adjuster throw down his clipboard and walk out. WiFi generally is in increasingly crowded bands. In my neighborhood, the list of WiFi networks I see anywhere in my home that are at -60db or higher (i.e. strong) is long. While it used to be that unsophisticated users would simply crowd onto whatever preconfigured channel their router used by default and I could avoid them by changing channels, newer APs and firmware seek out the less-crowded channels automatically and spread out, so now every channel has a dozen competing networks at 2.4Ghz (relatively few I've found can do 5Ghz). Z-Wave's band has actually become less crowded over time (my neighbors finally abandoned their 20-year old cordless phones, I guess). Configuration and security also becomes an issue: rare is the home user that understands that IoT devices should be isolated from the rest of the network. Their eyes glaze over when you talk about VLANs, firewalls, and DMZs. They don't understand IP addressing, and will use the default /24 subnet their router offers and the small dynamic DHCP pool until the day they add that last Shelly device and now the wife's phone can't get an IP address when she comes home, etc. They will run their vendor-supplied AP at 100% with half-a-dozen 4K WiFi camera streams and wonder why their "Internet" is always slow (they don't even understand the difference between their Internet access and their WiFi network). There's a learning curve to building a solid, secure IP network with WiFi that most users have been shielded from forever and (were told) needed to know nothing about, but if you're going to start putting dozens of IP/WiFi devices on your home network, you'd better learn it and know it and do the work it takes to do it right at scale, or it will bite you hard from the inside or worse, the outside, soon and often.

I've got some BLE in my network as well, and it works well for its purpose (mostly presence sensing). I remain curious, even intrigued, but...

The biggest issue I find, and what I would guess-timate is the biggest barrier to finding a "one protocol to rule them all" today, is that there are no manufacturers that cover the full spectrum of required devices on a single protocol. Nobody makes everything you want, regardless of protocol. So we're left to find the best of breed in each category. I don't see that changing any time soon, or really, ever. The manufacturers follow the money. Smaller manufacturers like Zooz will make a good business out of filling holes that the big guys don't want to address (looking at the ZEN-32 for example). The big manufacturers will always make what they can sell the most, like switches and dimmers.

Matter, HomeBridge, and the like... they are effectively controlled by large corporations that are explicitly disinterested in working with small developers. Claiming open source while you maintain a closed, expensive, and opaque certification process doesn't fly for me. Z-Wave, admittedly, shares some of these ills in its proprietary history, but has been evolving to increasingly open over the last five years, with multiple vendors now producing silicon and that competition driving lower cost to implement. Z-Wave is also pretty much a single-interest ecosystem, where Google, Apple, Amazon, Samsung, and others involved in the likes of Matter and HomeBridge have many areas of research and development, and have been shown to quickly and suddenly divest themselves of technology they decide isn't worth continued effort. The players here have been bad actors in the past; I have no reason to believe they will behave differently in future.

Like others have said, beware the cloud. Eschew the cloud. It's sometimes a necessary, unavoidable evil, but you'd best minimize it.

OK. First suggestion here, go to the Tools tab, and in very small print in the footer of the page area, you will see a link that says Clear Local Storage. Hit that link, answer the confirmation question, and then hard-refresh the browser.

Those errors are benign -- they just say that there's a Rule or Reaction in the Rule or Reaction history that no longer exists (or it's a sub-reaction, like a Group or Repeat/While action in a Reaction). Everything else is as expected. There are probably a dozen or so lines preceding this screen shot that could have other errors, but since it got this far, I doubt it. Confirming... this is while "Loading Reactor..." is still the only thing displayed on the screen?

Also what was the prior build of Reactor you were using? Were you far behind, or just a build or three?

Since I don't have any Apple products, I don't really support Safari. That's stated in the docs. I'm happy to chase this a bit to see if we can figure it out, but only to a point.

Expected and known. Will be addressed later. Constraints are updated when the rule is evaluated.

@therealdb said in Home Assistant Connect ZWA-2 & ZBT-2:

are external Zwave controllers supported via USB?

Not an expert here, since I've never really embraced my C7 as a core of my home, but based on a little digging apparently not. The predecessor SmartThings hubs did, but as of the C7, the hub lacks the drivers to support an external Z-Wave stick, only its own internal chip. I'm sure C8 is even more entrenched.

Like many of us, I have a hundred+ Z-Wave devices in my home. If there's an upside to a piecewise migration, it's that it isn't Vera. Pairing was always a slow, anxiety-inducing activity on Vera... one device... maybe pairs... Luup restart (90 seconds or more before system is stable enough to proceed)... maybe bricks the Vera... if not, two identical devices end up with different configuration/capability... horrible. When I moved one level of my house to a USB stick last year, I could almost pair devices as quickly as I could walk up to them. You can tell me if the ZWA-2 experience is similar (can you walk it around self-powered or with a USB battery pack and pair devices?). It's not as easy as a migration, but there's always something to be said for starting with a clean slate, and as long as the process is smooth and I get to keep my hair and sanity by the end of it, I'll put up with the time it takes to get there.

Going forward, thinking to what may follow, I assume that you can back up the NVM on the ZWA-2?

Just on a lark, I took a little distraction trip on the Elevation downloadable (local/manual) backup files. It turns out, the backup files are compressed and encrypted, and I found all the resources for undoing all of that, but it's not productive to do it because the files don't have a copy of the NVM data on them, which is a bummer. The C7 to C8 upgrade process apparently worked because it used cloud-based backup and offered additional "Migrate radio" options for Z-Wave and ZigBee, which presumably pushed the additional radio data up to the cloud specifically for that process; no local option. So no win to be had from the backup files, it appears.

@therealdb said in [MSR] Feature request: For Each action on arrays/groups:

There's no way to filter the group devices.

This is a comment I'm curious about, because there actually is a way to filter a group. But that may not be much help on its own without a couple of additional changes. I am working on parameters for reactions. I think that will address the need for different scripts. Delays in scripts also came to mind when I did the alarm() function, so that's a distinct possibility in the near future. I'm bookmarking this thread so that the work I'm doing on reactions trends toward making this easier. Thanks for the detail!