Best add some error detection, then.
Global Moderators
Forum wide moderators
Private
Posts
-
Existing Rule stopped working HTTP command fetching IP address from website -
Existing Rule stopped working HTTP command fetching IP address from websiteIn your
x_vera_device.set_variableaction, where you have the substitution${{ myIP }}, change it to${{ trim(myIP) }}Ref: String Functions
-
Existing Rule stopped working HTTP command fetching IP address from websiteThe endpoint has 15 seconds to answer by default (i.e. default timeout)... that's a long time for such a simple request.
https://icanhazip.comis a popular choice for this purpose, apparently, and may be more reliable. Its response is plain text rather than JSON, but based on your use, that's more direct.In any case, network errors are a fact of life, and requests will fail. If that's important to your process, error handling should be added (e.g. detect failed requests and skip changing the Vera variables).
-
Existing Rule stopped working HTTP command fetching IP address from website@cw-kid The capture variable having a null value is a pretty indication that there was an error. You have the "Suppress alerts on HTTP errors" box checked, so you're silencing your first option for notification of an error on the request. But then, there could be another location...
-
Raspberry Pi 4 dual RAM variant introduced to mitigate RAM price increasesArticle here that may be of interest to some:
Raspberry Pi 4 dual RAM variant introduced to mitigate RAM price increases and supply challenges - CNX Software
Desperate times call for desperate measures. Raspberry Pi has decided to introduce a dual RAM variant of the Raspberry Pi 4 to allow DRAM supply chain
-
Condition for trendVirtualEntityController can sample another entity's data and do time-series aggregation (moving average, rate of change, etc.).
Refer to the documentation for VirtualEntityController
-
Set reaction triggering wrong z-wave deviceThe name is incorrect at ZWave-JS (on the node itself) if that's the case, so to keep your sanity later, make sure you go all the way back to the source and work your way forward from there.
-
Set reaction triggering wrong z-wave deviceReactor only changes the entity name when the entity is first created. From there on, it sticks, no matter what the underlying hub does. To change the name, hit the "Rename" button on the entity in the detail pane (see your latest screen shots).
Also future note. When posting log snippets, please don't use
grepor other filtering. Find the lines of interest, and post 20-25 of context before and as much context after as is relevant. Not all relevant log messages may contain the string you are searching for. -
Set reaction triggering wrong z-wave device@tamorgen said in Set reaction triggering wrong z-wave device:
Here are some logs of me turning the entities on and off from HAAS.
You've shown here all stuff from ZWaveController, not HassController...? I don't think that would be helpful here anyway, because it would only show the HA entity IDs, and HA doesn't embed ZWave node numbers in their entity names. You would have to go look at the device in HA to confirm the node numbers. In HA's UI, go to Settings > Integrations > ZWave > Devices. Find the device you think is your Front Porch Lights switch, and click it. In the Device Info area, there's a Z-Wave Info heading with an arrow — click the arrow to expose the node number.
You said you updated ZWaveJSController, but it's still not showing me the expected log data. Can you confirm that in the startup messages for Reactor, ZWaveJSController reports it is version as 25304. If not, your update was not successful.
You can also go back to the ZWave-jS UI and command node 137 on from there, and see which device ZWave-JS switches. If it's the same device that Reactor switches, your Z-Wave nodes or HA devices are incorrectly identified.
What is clear in the Reactor logs so far is that ZWave node 137 is being told to do something, and ZWave node 137 responds back that it received the command its values changed. Nowhere along the way do the logs mention 136. If there was something wrong with what ZWaveJSController was commanding ZWaveJS to do, I would expect it log that it was performing an action on 137, but then gets update reports from 136, and that's not what is happening. I can also see in your Z-Wave data that node 137 is named "Front Porch Lights" at the node itself, which is consistent with the Reactor entity name, so Reactor/ZWaveJSController thinks it is doing the right thing.
I would start looking at the root, which is the ZWaveJS-UI, and make sure that node 137 is really your porch lights and you can command them on and off from there. If that's not the case, change the device name in Z-WaveJS UI, and then make sure the names in both HA and Reactor for nodes 136 and 137 match that data. Right now, it appears they do not.
-
Set reaction triggering wrong z-wave deviceOK. Everything checks out there. I would upgrade to the latest ZWaveJSController -- it looks like you are a release behind. That version added logging for what is actually sent to ZWaveJS, which may be instructive. But restarting for that update and rebuilding the state data may resolve the issue (you've probably done the former, I assume, but the latter is less obvious), so we're changing the conditions of the test. But let's see what happens when you upgrade, and then see what the log entries look like if the behavior is the same, because it sure looks like ZWaveJSController has it correct.
