@toggledbits Is that in the reactor.yaml file? I don't have the old one configured there. It just automatically worked. Influx section of my reactor.yaml is below with most of the commented lines removed.

plugins:
  - id: influx
    # See the docs under Standard Plugins for configuration details.
    implementation: InfluxFeed
    enabled: true
    name: InfluxDB Feed
    config:
      # influx_url - URL to access InfluxDB server (default: http://localhost:8086)
      influx_url: http://192.168.0.X:8085
      
      # influx_org - Organization ID (required)
      influx_org: "org1"
      #
      # influx_bucket - Bucket name to which points are written (required)
      influx_bucket: "msrdata"
      #
      # ----- For InfluxDB 1.8+ ONLY -----
      # influx_database - Database name for data storage (required)
      influx_database: "reactor"
      #
      # influx_username - Username for database access (required)
      influx_username: "reactor"
      #
      # influx_password - Password for database access (required)
      influx_password: "mypassword"
      
      select_capabilities:   
        light_sensor: true   
        temperature_sensor:
          attributes:
            value:
              type:number
            units:
              type: string
        x_hubitat_extra_attributes:
          attributes:
            cpu5Min:
              type: number
            cpuPct: 
              type: number
            freeMemory:
              type: number
            dbSize:
              type: number
        wx:
          attributes:
            - temperature
            - humidity
            - cloud_cover

So I think it should be picking it up from the 'x_hubitat_extra_attributes'. The new hub information device also has those attributes when I examine it in Entities.

Edit: Found it --- the Grafana chart was filtered on 'WHERE name = Hub Information'
when i removed that, the data (which was never really missing) appeared on the chart.

Before:

After:

and digging a little further: I changed the capitalization on the device name when I recreated it:

MSR latest-22310, Raspberry Pi 4 / Docker

While troubleshooting another issue, I deleted and recreated the hub information device on one of my Hubitat hubs. Reactor had been logging the old device information to InfluxDB, but it doesn't appear to have detected the new device. I made sure to enable the new device in Maker API, I've restarted reactor and done a 'docker-compose down' / 'docker-compose up - d'. Still no new data going to influxdb.

My recollection is that the Hubitat hub device is baken into MSR and is auto-detected, and that it isn't manually configured anywhere. I checked the docs and searched the forum without success.

Any advice on how I can get MSR to start logging the info from the new device?

I don't know if this helps for other Docker users, but not long after I got started with Docker I found Portainer, and I've been running it alongside Reactor and my other containers on my Raspberry Pi 4. With Portainer, there may not be a one-step update button, but I find it makes updates much easier.

I just updated Reactor to the latest. All I had to do was go to the Portainer URL in my browser, then

• Click on the Reactor container in the Containers list

• Click 'Recreate"

• Toggle "Always pull new image" on the window that pops up

• Click "Recreate"

It isn't one click, but it can be done in a browser tab from any machine with network access to the Docker host. No VNC/SSH into the machine, no Docker commands to run from the command line.

Portainer also has links to view the container logs and to open a command window in the container, which I use all the time. You can also use the "duplicate/edit" button to change or add environment variables while updating, which is how I added the NODE_PATH a few updates back.

So it works just like most of the other elements in MSR.

Move along people... nothing to see here... just me missing the obvious.

Maybe a dumb question if I'm missing something obvious, but I checked the manual and searched the forum without finding anything relevant...

Can the Rule Sets on the left side of the MSR web UI be re-sorted? I just realized that it seems to be sorted with the newest ones at the top and I would prefer to have them alphabetical... and to have a multi-level tree with nested rulesets... but I'll settle for alphabetical for now if there's a way to do it

MSR latest-22266 / Raspberry Pi 4 / Docker

Excellent. I'll read up on that and figure out whether the node-red or VirtualEntityController route is cleaner.

Thanks!

Checking in on this, because I'm still struggling with getting this data logged. My other option is to set up a logger in NodeRed where I already have all the data coming over by MQTT, and I would have to set up the database connection and queries to push the data over from there. How far down on the wish list is this? If it's not anywhere near the top, I will probably try the NodeRed route.

@toggledbits I've tried editing the headers field to add and then remove a space, and I tried deleting the headers entirely. That caused them to default to "Content-Type: application/x-www-form-urlencoded". I saved that and then changed it back to the application/json header. Still getting the error.

TLDR: I'm getting an alert saying I have to edit and re-save a rule containing a HTTP POST request in order to update it, but following the instructions in the alert doesn't seem to fix the issue.

I am receiving this message in the Current Alerts when sending a HTTP POST request.

The action at step 1 of "Send Notification Reaction" (re-I7yq7e15) needs to be edited to update it to the latest stored form. The action will continue, but should be updated as soon as possible, before this form is deprecated and no longer functions. Just make a trivial edit to the "headers" argument and then save the reaction to update it.

Details:

I am using a self-hosted notification system - Gotify. Many of my rules use a HTTP POST action to send a notification through this system. The message contains a JSON body with the title, body, and message priority. It is posted to a URL on my LAN where the Gotify server resides.

When I updated to latest-22252-65e94b36 I started to receive the above error. Since I had the http request in many rules I took the opportunity to simplify things by moving the http request to a Reaction in the Reactions section of MSR. I created two variables to pass the notification content to the Reaction and now send all notifications via the one Reaction. Each rule that needs to send a reaction sets the variable values and then runs the Reaction.

For example, this rule runs if the Kitchen Main leak sensor detects a leak. It sets the variable "g_gotify_token" to a value (this is used as part of the URL when making the HTTP request) and sets "g_gotify"body" to a JSON formatted string. In this case that string is

{ "title":"Water Alert", "message": "Kitchen Main Leak Sensor Tripped", "priority": 8 }

Finally, the rule runs the Reaction "Send Notification Reaction"

That reaction contains the http request. It uses the variables in the URL and request body fields. The request headers field is static and is set to "Content-Type: application/json"

I get the same error when I directly call the HTTP request from a rule without using any variables. Either way, the notification goes through successfully. The only issue is the alert being raised in MSR.

I tried editing and re-saving the Reaction, and also tried creating an entirely new reaction. I get the same warning message either way.

footnote: Because I use the same process to send a notification whenever there is an alert raised in MSR, this also created a loop (that thankfully got throttled pretty quickly) where the system was making the http request to send a notification that this alert had been raised, and the action of sending that notification raised the alert again... etc...

Is this just a bug? Am I missing something about the request format that needs to be updated? I checked the manual and this forum for answers, but didn't find anything that looked relevant.

@gwp1 I was away from the forum for a few days, but to answer your question, I use the Hubitat app for Android on my phone and my wife's phone to determine presence. Every once in a while they break it with an update and I can use the Google assistant presence instead. I prefer Hubitat because you can set a geofence and I have them set up not to consider us away when walking the dogs in the neighborhood, but to have us away when we're at my parent's house just outside our usual walking route. Google doesn't give me that level of control over what's considered home or away.

Just a curious onlooker here... why aren't you just letting the Hubitat set these statuses? Is it just a desire to keep all the logic in Reactor? I have Hubitat Mode Manager configured to set Day at sunrise and Night at sunset +30 except when the mode is Away. It sets Away when all users leave, sets Day when any user returns between sunrise and sunset +30, and it sets Night when any user returns between sunset +30 and sunrise. I'm using the Hubitat app for presence sensing, and it looks like you're using HASS, so maybe that makes keeping the log in Reactor a better way to go.

I have rules in Reactor that depend on the status (like switching modes in Blue Iris or changing modes on IP cameras), but the basic status determination comes from my Hubitat and it works flawlessly. Now that I said that, it's going to fail tonight

@black-cat I run Reactor and Portainer on a Pi4 without any issues.

The Pi is running Node-Red (bare metal), and in Docker: Teslamate (includes Teslamate, Grafana, Traefik, PostgreSQL, MQTT), Reactor (includes InfluxDB for Reactor, Chronograf, Telegraf), Gotify (a self-hosted notification platform), and a Tesla Powerwall integration (includes 2nd instances of Telegraf and InfluxDB, Grafana, and pypowerwall). Fifteen containers when you add Portainer itself. The Portainer GUI makes this all much easier to manage.

@rogero See this thread: https://smarthome.community/topic/706/notifications-from-alerts/3

I'm running latest-22080-ae7212f under Docker on a Raspberry Pi 4. MQTT is running in a docker on the same Pi.

I have a rule that should notify me if my MQTT broker is offline and make an http call to Node-Red to attempt to restart the MQTT container.

If MQTT is offline and I restart Reactor, I can see in the logs that it tries to connect to MQTT for a few seconds before it appears to time out. When Reactor finishes its restart I get the notification.

However I just tested it by taking the MQTT broker down while Reactor was already up and running, and after about 5 minutes it hadn't detected the MQTT system status as down. How long should it take for Reactor to notice that the MQTT system is down outside of a Reactor restart? Or will it not detect the broker offline except at the initial connection attempt?

@gwp1 I'm not actually doing this, that was just my thoughts on how it could be done (= untested speculation ). I think it would have to be two rules. That way each rule is firing at one specific date and time and you wouldn't be trying to create a rule that is active at all dates and times between DST start and DST end, which I think leads you down the OP's path using latching. If you have one rule with a reset action there's no need for the expression, you could just use the rule state to tell if it's DST.

I tried to follow your example but I'm confused. Shouldn't the "and the rest" rule start on April 1st instead of March 1st? I'm definitely not a latching expert, so maybe I'm the wrong person to try to understand what you've done.

Not being competent with latching, the approach I would probably take would be to create an expression 'is_dst' and have a rule that sets it to true on the second Sunday of March at 0300 and sets it to false on the first Sunday in November at 01:59:59. Initially set it to the correct value and then just refer to the expression whenever a rule needs to know if DST is in effect. Seems simpler to me and I think it would work just as well.

My state legislature is considering a bill to stay on DST permanently. It would require federal approval, so it's probably not going to happen anytime soon, but there's another way to solve the problem.

Just realized I was only looking in the Hubitat.log file, which we turned on while trying to troubleshoot something else, and not in the reactor.log file... Ugh... need more coffee before trying to troubleshoot. Apologies for making this more difficult by missing that. In the reactor.log files I found the Influx errors saying that the database field was type 'float' and the data from the hub was 'string'. If I had posted that at the top of this thread, it would be a much shorter read.

After changing the attributes as you showed above I'm now getting correct data into the database and I'm not seeing errors in reactor.log.

@toggledbits I wasn't expecting a reply until you got back from vacation and handled other higher priority things, but I'll try to add the additional information now:

What I'm expecting is that each time the data on the Hubitat Hub Information device changes, that the values for that I added in my reactor.yaml file (cpu5Min, cpuPct, freeMemory) will be written to the influx database. This is what it was doing up until two days ago, and I think the change in behavior matches up to when I upgraded to 22067.

The Grafana queries are not using aggregates, nor was the direct query I ran from Influx via the command line, but I should have posted the query I used to pull the data. Here is data I just pulled directly from Influx using a command prompt, filtering on only one hub to make it simpler:

> select * from x_hubitat_extra_attributes where entity = 'hubitat>483' order by time desc limit 6
name: x_hubitat_extra_attributes
time                controller cpu5Min cpuPct entity      freeMemory name
----                ---------- ------- ------ ------      ---------- ----
1646918045910000000 hubitat    0.23    5.75   hubitat>483 324088     Hub information
1646918032714000000 hubitat    0.23    5.75   hubitat>483 324088     Hub information
1646916245576000000 hubitat            3      hubitat>483 325848     Hub information
1646916119494000000 hubitat            3      hubitat>483 325848     Hub information
1646914445106000000 hubitat    0.11    2.75   hubitat>483 325904     Hub information
1646914238104000000 hubitat    0.11    2.75   hubitat>483 325904     Hub information

Starting from the bottom of the list with the oldest two records, they are about 4 minutes apart but show the exact same numbers.

The next two records again are about 4 minutes apart and show the same numbers.

The top two records are about 1 minute apart and show the same numbers.

Between each pair of logged values I restarted Reactor. On the last set - the top two in this list - I was watching the Reactor Entities screen and saw that the Hub Information entity updated at the time the last data point was stored, but the values were NOT 0.23, 5.75, and 324088.

I can upload logs when you get back. I looked at the times in the log when this data was stored and I don't see anything related to Influx. I do see the updates coming from the Hub Information device.

I was able to find the logs corresponding to the two records in the middle (showing 325848 as the freeMemory)

The timestamp on the older one converts to: Thursday, March 10, 2022 12:41:59.494 PM

In the logs I find the value for the freeMemory a few minutes earlier at 12:39:05Z. I think the time discrepancy is because I restarted Reactor between when the value was logged and when it got written to the database. When Reactor started up, it wrote the most recent value to Influx.

[latest-22067]2022-03-10T12:39:05.568Z <HubitatController#hubitat:5:HubitatController.js:641> HubitatController#hubitat received DEVICE event [Object]{ "source": "DEVICE", "name": "freeMemory", "displayName": "Hub information", "value": "325848", "type": "null", "unit": "KB", "deviceId": 483, "hubId": 0, "installedAppId": 0, "descriptionText": "null" }
[latest-22067]2022-03-10T12:39:05.569Z <HubitatController#hubitat:INFO> HubitatController#hubitat fast update Entity#hubitat>483 event freeMemory="325848"
[latest-22067]2022-03-10T12:39:05.569Z <HubitatController#hubitat:INFO> HubitatController#hubitat fast update Entity#hubitat>483 event freeMemory="325848"

The next record from the database with the same values has a timestamp that converts to Thursday, March 10, 2022 12:44:05.576 PM

That matches up in the logs with this:

[latest-22067]2022-03-10T12:44:05.632Z <HubitatController#hubitat:5:HubitatController.js:641> HubitatController#hubitat received DEVICE event [Object]{ "source": "DEVICE", "name": "freeMemory", "displayName": "Hub information", "value": "325884", "type": "null", "unit": "KB", "deviceId": 483, "hubId": 0, "installedAppId": 0, "descriptionText": "null" }
[latest-22067]2022-03-10T12:44:05.633Z <HubitatController#hubitat:5:HubitatController.js:643> HubitatController#hubitat ws DEVICE event device 483 freeMemory="325884"
[latest-22067]2022-03-10T12:44:05.633Z <HubitatController#hubitat:INFO> HubitatController#hubitat fast update Entity#hubitat>483 event freeMemory="325884"

So at 12:44:05 I'm expecting the freeMemory written to the database to be 325884, but the database query returned 325848, the previous value from a few minutes earlier in the logs.

The next instance of the hub freeMemory in the logs is at 12:49:05Z

[latest-22067]2022-03-10T12:49:05.763Z <HubitatController#hubitat:5:HubitatController.js:641> HubitatController#hubitat received DEVICE event [Object]{ "source": "DEVICE", "name": "freeMemory", "displayName": "Hub information", "value": "325664", "type": "null", "unit": "KB", "deviceId": 483, "hubId": 0, "installedAppId": 0, "descriptionText": "null" }
[latest-22067]2022-03-10T12:49:05.764Z <HubitatController#hubitat:5:HubitatController.js:643> HubitatController#hubitat ws DEVICE event device 483 freeMemory="325664"
[latest-22067]2022-03-10T12:49:05.765Z <HubitatController#hubitat:INFO> HubitatController#hubitat fast update Entity#hubitat>483 event freeMemory="325664"

There is no corresponding record in the Influx database. I would expect an entry with freeMemory of 325664.

There are additional logs showing the Hubitat Hub Information device updating values every few minutes, but nothing was added to the database until after 1:13:52Z when I restarted Reactor. Then I got the two entries showing a freeMemory of 324088, but as with the middle two record in the query results, the second one of the pair is wrong. The last (top of the list) data in the database shows freeMemory of 324088 and its timestamp converts to Thursday, March 10, 2022 1:14:05.910 PM

The log shows:

[latest-22067]2022-03-10T13:14:05.943Z <HubitatController#hubitat:5:HubitatController.js:641> HubitatController#hubitat received DEVICE event [Object]{ "source": "DEVICE", "name": "freeMemory", "displayName": "Hub information", "value": "323712", "type": "null", "unit": "KB", "deviceId": 483, "hubId": 0, "installedAppId": 0, "descriptionText": "null" }
[latest-22067]2022-03-10T13:14:05.945Z <HubitatController#hubitat:5:HubitatController.js:643> HubitatController#hubitat ws DEVICE event device 483 freeMemory="323712"
[latest-22067]2022-03-10T13:14:05.945Z <HubitatController#hubitat:INFO> HubitatController#hubitat fast update Entity#hubitat>483 event freeMemory="323712"

I would have expected the database entry at 13:14:05Z to show 323712 as the freeMemory value.

I haven't restarted Reactor since then, and as I type this several hours later, no new data for these attributes has made it into the database.

Reactor latest-22067 on Raspberry Pi, Influx DB 1.8, both in Docker. Controlling two separate Hubitat C7s.

I am storing data for CPU load and free memory from the Hub Information device on the Hubitat Hub in the Influx database so that I can graph them.

I noticed that for the last two days I was not getting the free memory on my graph. (I don't currently graph the CPU data.) When I restarted Reactor I got two data points and then nothing for a while.

I looked at the Hubitat Hub Information device and could see the numbers changing there. I also watched the entities screen in Reactor and could see it flash green when it updated. Both the Hubitat device and the Reactor entities matched and were updating.

However the Influx database stopped getting new data. What I see in Grafana matches what I see when I directly query the database in a terminal window, so it is not an issue with Grafana.

The Hub Temperature data is updating in the database every time it changes. It is not one of the extra attributes that I added. It is logged as a regular temperature_sensor.

This is the relevant portion of reactor.yaml:

      select_capabilities:   
        light_sensor: true   
        x_hubitat_Thermostat:
          attributes:
            - coolingSetpoint
            - heatingSetpoint
            - thermostatFanMode
            - thermostatMode
            - thermostatOperatingState
            - thermostatSetpoint
            - temperature
        x_hubitat_extra_attributes:
          attributes:
            - cpu5Min
            - cpuPct
            - freeMemory
        wx:
          attributes:
            - temperature
            - humidity
            - cloud_cover

This chart from Grafana illustrates what is happening. The data points circled in red are the pairs of points from two restarts of Reactor. The yellow line and green line represent the two separate Hubitat hubs that I'm connected to. The blue line is the CPU temperature from one of the hubs.

Here is the same graph from a little later to show the CPU temp is continuing to update, but the free memory is not:

Again, the free memory is changing in the entities screen every time it changes in the hub, but the data isn't being saved to InfluxDB after the first two data points.

Looking at the most recent documentation, I saw the format for the attributes was different, using a trailing ":true" intead of a leading "-", so I tried switching my reactor.yaml to match. The section now reads:

    x_hubitat_extra_attributes:
      attributes:
        cpu5Min: true
        cpuPct: true
        freeMemory: true

I restarted Reactor and got the same result.

Final observation... the second data point in each pair is incorrect...

After the last restart I pulled the data from the database.

time                controller    cpu5Min cpuPct entity            freeMemory name
----                ----------    ------- ------ ------            ---------- ----
1646918194198000000 hubitat_11705 0.07    1.75   hubitat_11705>130 526192     Hub information
1646918045910000000 hubitat       0.23    5.75   hubitat>483       324088     Hub information
1646918032985000000 hubitat_11705 0.07    1.75   hubitat_11705>130 526192     Hub information

The first and third lines are relevant here. They are both for the 'hubitat_11705' hub. They show the free memory as 526192 on both lines.

But when the second data point was saved to the database the reactor entity showed:

x_hubitat_extra_attributes.freeMemory="525728"

and the Hubitat device shows:

So the second data point should have been saved in the database as '525728' but instead it saved the previous value of 526192.

Looking back at the annotated Grafana graph I can see the same thing happened with the earlier pairs of points... the second point was the same value as the first, and then there was no more data logged until the next Reactor restart.

Option 2 seems like the way to go. I'll make that change and wait for nothing to happen