I updated to the latest version and it is working with Digest auth and the new username / password fields. You are going to spoil us with this pace of development

@wmarcolin

I'm still trying to try one of these things and not have @toggledbits come in right behind me and show a much easier way. Maybe this time I'll get lucky.

I came up with this:

Based on the comments from the more experienced users here I ordered a Hubitat this morning and Amazon had it to my door about 3 hours later. After a few z-wave network resets to try to resolve one switch that just won't configure, I have about 90% of everything migrated over to Hubitat. Vera still has a few SiteSensors (I need to read up on the threads about replicating site sensors on MSR) and some Yeelight bulbs that are on a separate VLAN from the Hubitat. I haven't found a way to connect them manually yet and the Hubitat can't discover them across the VLANs.

I'm still trying to figure out a way to use Google Home to flip a virtual switch in Hubitat to then trigger a http call from MSR. There are a few things I was doing with Vera scenes to achieve a similar effect, but MSR doesn't seem to be able to see Hubitat virtual devices.

I'll probably keep the VeraPlus going for a while with the Yeelights and the SiteSensors while I figure the rest of this out.

Thanks for the advice.

+1

I am getting occasional network timeouts on a http request that repeats every two minutes (it is emulating a SiteSensor that I had on Vera). I'd like to be able to suppress those alerts as they are expected to happen from time to time and not anything I need to be notified about.

Edit:
Nevermind.... I posted here before looking at the update you just posted in the announcements thread... I see you already made this change.

I took the UserName and Password, used a base 64 encoder and input "UserName:Password" into the encoder. I took the output of the encoder ("ABCDEFGXXX") and entered (no quotes) "Authentication: Basic ABCDEFGXXX" into the http headers field. I have another http request in another rule that hits an API to control my thermostat and it work correctly using exactly the same process.

The logs don't appear to make any reference to the http header:

[latest-21297]2021-11-01T22:21:55.816Z Engine:INFO Set PTZ Camera to Day Mode rule<SET> all actions completed.
[latest-21297]2021-11-01T22:21:55.845Z Engine:ERR Engine#1 reaction Set PTZ Camera to Day Mode rule<SET> step 3 HTTP request to http://xxx.xxx.xxx.xxx/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=18&arg3=0 failed: 401 Unauthorized
[latest-21297]2021-11-01T22:21:55.854Z Engine:ERR Engine#1 reaction Set PTZ Camera to Day Mode rule<SET> step 1 HTTP request to http://xxx.xxx.xxx.xxx/cgi-bin/configManager.cgi?action=setConfig&VideoInMode[0].Config[0]=0 failed: 401 Unauthorized

Prior to attempting to use the http header field I had tried the below format, with the username and password in front of the URL:

[latest-21297]2021-11-01T12:58:08.125Z Engine:ERR Engine#1 reaction Set PTZ Camera to Night Mode rule<SET> step 3 HTTP request to http://UserName:Password@xxx.xxx.xxx.xxx/cgi-bin/configManager.cgi?action=setConfig&VideoInExposure[0][1].Value1=1000&VideoInExposure[0][1].Value2=1000 failed: 401 Unauthorized

I did get this working in Node-Red using digest authentication in a http-request node, so it probably isn't worth too much of everyone's time to track it down. I would prefer to have it in MSR because it is so much more user-friendly for me, but I can leave it in Node-Red if I can't figure out how to do it in MSR.

@toggledbits - Long overdue additional donation on its way. Thanks for all your efforts and the end-user support.

Resurrecting this older thread... does this answer mean there is no way to react to the presence of an alert within MSR? If not, this would be a useful enhancement.

I have a camera that is switched between day and night settings by http requests sent by MSR near sunset and sunrise. Yesterday the camera stayed in night mode most of the day while there was an alert showing in MSR that the http request had failed. I realize I could capture the http response to an expression/variable and then write a rule based on that variable to notify me, but I'd have to do this for every http request in every ruleset, and I'd have to make sure I evaluate the response correctly (which is likely to be a hit or miss operation for me). That still wouldn't capture other alerts that MSR might display outside of failed http requests, but I'd like to push all alerts to my notification system. Basically, I don't want to have to check the MSR interface to make sure it's happy, I'd like it to tell me when it's not.

Just a note for posterity that alerts are now available as an entity as of version 21356.

@cw-kid I'm sure there are multiple ways to do this, and probably some better than what I'm thinking...

Create an expression "g_curtains_open_today"

Create a rule. At midnight every day set g_curtains_open_today to false

Motion sensor rule: If motion sensor trips AND g_curtains_open_today is false then:

-> Open curtains
-> set g_curtains_open_today to true

The next time the motion sensor trips before midnight the curtains will not open

@Crille Thanks! I was a bit confused when I first read that section of the MQTT documentation but your example using the topics from my own system helped clear it up for me.

I made a slight change to the template to make it "teslamate/cars/%topic%" which allows me to re-use it for multiple binary entities for both cars by using for example "topic: "1/locked" and "topic: 2/locked" for two entities in reactor.yaml.

I also hit a snag where trying to directly copy:

    entities:
      teslamate_sensor:
        type: BinarySensor
        capabilities: ['binary_sensor']
        primary_attribute: binary_sensor.state

caused Reactor not to start with a yaml formatting error, but referring to the documentation I changed it to:

    entities:
      teslamate_sensor:
        type: BinarySensor
        capabilities: 
          - binary_sensor
        primary_attribute: binary_sensor.state

moving the capability down one line with a leading "-" and it works.

Now I just have to find the time to write all the rules that are possible with the car information available in MSR...

They are not using the Hubitat mesh. They are completely separate.

@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

@toggledbits So it took quite a while to capture a missed reaction, but I had one this morning. The Hubitat log shows a switch turn on twice. The (virtual) switch is set to auto-off in Hubitat. The reactor log shows the reaction only fired the second time the switch was turned on. What's the best way to send you the logs?