SmartHome Community

Alan_F

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

Alan_F

@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:

Alan_F

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.

Alan_F

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

Alan_F

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.

Alan_F

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.

Alan_F

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

Alan_F

@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

Alan_F

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

Alan_F

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

Alan_F

@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:

Alan_F

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?

Alan_F

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.

Alan_F

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

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

Alan_F

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

Alan_F

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

Thanks!

Alan_F

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.

Alan_F

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

Alan_F

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.

Alan_F

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

Migrating Zwave & ZigBee stuff to MQTT - guidance needed.

RPi Alternative: Libre Computer AML-S905X-CC "Le Potato" (2GB RAM)

latest-22328 restart fails

Virtual HTTP Devices plug-in - light bulb status

Reactor (Multi-System/Multi-Hub) Announcements

Update from 22240 to 22310 failed. New Install also failed. (Windows)

ESP32 / ESP8266

openLuup: Version Log

Where Used Functionality?

Using MSR with BrowserMod to change pages/dashboards

reactor-lgtv: LG TV Controller for Reactor

MQTT templates for Reactor

Light automation thoughts

3-way smart switches in separate buildings.

[MSR] More aggressive interval in timer trigger

Device that comes on on Openluup restart

Pulse

Device issues in Open Luup

Error message

Alan_F

@Alan_F

Best posts made by Alan_F

Latest posts made by Alan_F