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
-
Hello,
I have a fresh openluup install on a raspberry.
Just installed "Vera Bridge" plugin, but I can't make it to work.
The plugin can not load the device infos from the vera.
This is what I can see in the OpenLuup log :openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
I have tried it from a console on the same raspberry this way :
wget http://192.168.1.2:3480/data_request?id=user_data2&output_format=json&ns=1
It worked, so I think it's not credential or network issue.What can be the solution for this ?
more openluup log :
408 lines, 1 error, max gap 61s @ 2022-08-12 20:51:01.568
2022-08-12 19:21:24.150 :: openLuup LOG ROTATION :: (runtime 0.0 days)
2022-08-12 19:21:24.154 openLuup.init:: init phase completed
2022-08-12 19:21:24.155 openLuup.io.server:: starting HTTP:3480 server on port: 3480 tcp{server}: 0x1c48ee8
2022-08-12 19:21:24.157 openLuup.io.server:: starting SMTP server on port: 2525 tcp{server}: 0x1b461d8
2022-08-12 19:21:24.158 openLuup.io.server:: starting POP3 server on port: 11011 tcp{server}: 0x1b48780
2022-08-12 19:21:24.158 openLuup.historian:: starting data historian
2022-08-12 19:21:24.159 openLuup.historian:: using memory cache size (per-variable): 1024
2022-08-12 19:21:24.168 openLuup.scheduler:: starting
2022-08-12 19:21:24.169 openLuup.scheduler:: [2] openLuup device startup
2022-08-12 19:21:24.170 luup_log:2: v22.7.31
2022-08-12 19:21:24.171 luup_log:2: sync in 35.8 s
2022-08-12 19:21:24.190 luup.variable_watch:: callback=housemode_watcher, watching=2.openLuup.HouseMode
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_email, request=openLuup@openLuup.local
2022-08-12 19:21:24.191 luup.register_handler:: global_function_name=openLuup_images, request=images@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_events, request=events@openLuup.local
2022-08-12 19:21:24.192 luup.register_handler:: global_function_name=openLuup_mailbox, request=mail@openLuup.local
2022-08-12 19:21:24.193 luup.chdev.append:: [AltAppStore] Alternate App Store
2022-08-12 19:21:24.193 luup.chdev.sync:: [2] openLuup, syncing children
2022-08-12 19:21:24.194 luup_log:2: starting MQTT $SYS/broker statistics
2022-08-12 19:21:24.196 luup_log:2: 3Mb, 2.1%cpu, 0.0days
2022-08-12 19:21:24.211 openLuup.scheduler:: [2] openLuup device startup completed: status=true, msg=sync in 35.8 s, name=L_openLuup
2022-08-12 19:21:24.212 openLuup.scheduler:: [3] Alternate UI device startup
2022-08-12 19:21:24.212 luup_log:3: ALTUI: initstatus(3) starting version: v2.54
2022-08-12 19:21:24.214 openLuup.scheduler:: [3] Alternate UI device startup completed: status=, msg=, name=
2022-08-12 19:21:24.214 openLuup.scheduler:: [7] VeraBridge device startup
2022-08-12 19:21:24.215 luup_log:7: VeraBridge
2022-08-12 19:21:24.215 luup_log:7: 2021.01.03
2022-08-12 19:21:24.216 luup_log:7: 192.168.1.2
2022-08-12 19:21:24.216 luup_log:7: device clone numbering starts at 10000
2022-08-12 19:21:24.217 luup_log:7: VeraBridge maps remote Zwave controller
2022-08-12 19:21:24.218 luup_log:7: v21.1.3
2022-08-12 19:21:24.242 openLuup.client:: WGET error status: -1, request: http://192.168.1.2/port_3480/data_request?id=user_data2&output_format=json&ns=1
2022-08-12 19:21:24.242 luup.set_failure:: status = 2
2022-08-12 19:21:24.243 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 2 now: 2 #hooks:0
2022-08-12 19:21:24.244 luup.variable_set:: 7.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1660323316 now: 1660324884 #hooks:0
2022-08-12 19:21:24.246 luup_log:7: registering with AltUI [3] as Data Storage Provider
2022-08-12 19:21:24.247 luup.register_handler:: global_function_name=HTTP_VeraBridgeMirror_192.168.1.2, request=HTTP_VeraBridgeMirror_192.168.1.2
2022-08-12 19:21:24.249 luup.call_action:: 3.urn:upnp-org:serviceId:altui1.RegisterDataProvider
2022-08-12 19:21:24.260 openLuup.scheduler:: [7] VeraBridge device startup completed: status=, msg=No Vera, name=VeraBridge
2022-08-12 19:21:24.261 openLuup.scheduler:: [4] Alternate App Store device startup
2022-08-12 19:21:24.261 luup_log:4: AltAppStore : starting...
2022-08-12 19:21:24.262 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine1 was: AltAppStore now: AltAppStore #hooks:0
2022-08-12 19:21:24.263 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine2 was: now: #hooks:0
2022-08-12 19:21:24.264 luup_log:4: AltAppStore : v20.3.30
2022-08-12 19:21:24.264 luup.set_failure:: status = 0
2022-08-12 19:21:24.265 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.266 luup.variable_set:: 4.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.267 openLuup.scheduler:: [4] Alternate App Store device startup completed: status=true, msg=OK, name=AltAppStore
2022-08-12 19:21:24.268 openLuup.scheduler:: [5] Harmony Hub Control device startup
2022-08-12 19:21:24.280 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.LinkStatus was: Ok now: Starting... #hooks:0
2022-08-12 19:21:24.281 luup.variable_set:: 5.urn:rboer-com:serviceId:Harmony1.IconSet was: 0 now: 3 #hooks:0
2022-08-12 19:21:24.282 luup.attr_set:: 5.altid = HAM5_CNTRL
2022-08-12 19:21:24.326 luup.set_failure:: status = 0
2022-08-12 19:21:24.326 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.327 luup.variable_set:: 5.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-08-12 19:21:24.328 openLuup.scheduler:: [5] Harmony Hub Control device startup completed: status=true, msg=OK, name=Harmony Control
2022-08-12 19:21:24.332 luup_log:3: ALTUI: UPNPregisterDataProvider(3,Vera@192.168.1.2,http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2,[{
"default":"device.serviceId.name",
"key":"mirror",
"label":"Mirror",
"type":"text"
}])
2022-08-12 19:21:24.337 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... #hooks:0
2022-08-12 19:21:24.360 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d21868
2022-08-12 19:21:24.363 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=323312852&Timeout=60&MinimumDelay=1500&=1660323303557 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:24.646 openLuup.server:: request completed (34267 bytes, 3 chunks, 280 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:24.648 openLuup.io.server:: HTTP:3480 connection from 192.168.1.24 tcp{client}: 0x1d6a9b0
2022-08-12 19:21:24.661 openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=323312340&=1660323303558 HTTP/1.1 tcp{client}: 0x1d21868
2022-08-12 19:21:25.252 openLuup.server:: request completed (70135 bytes, 5 chunks, 588 ms) tcp{client}: 0x1d21868
2022-08-12 19:21:25.253 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3
2022-08-12 19:21:25.338 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Version was: v2.54 now: v2.54 #hooks:0
2022-08-12 19:21:25.934 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"Vera@192.168.1.2":{"url":"http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.2","callback":... now: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... #hooks:0
2022-08-12 19:21:25.964 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"thingspeak":{"url":"","callback":"sendValueToStorage_thingspeak","parameters":[{"type":"number","key":"channelid"... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.996 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.DataStorageProviders was: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... now: {"emoncms":{"url":"","callback":"sendValueToStorage_emoncms","parameters":[{"default":1,"type":"number","key":"node... #hooks:0
2022-08-12 19:21:25.999 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToSend was: now: #hooks:0
2022-08-12 19:21:26.009 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.RemoteVariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.010 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.VariablesToWatch was: now: #hooks:0
2022-08-12 19:21:26.012 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Timers was: [] now: [] #hooks:0
2022-08-12 19:21:26.013 luup_log:3: ALTUI: Wkflow - enableWorkflows(3,0,0)Thank You.
d. -
Been trying to call the service automation:trigger to trigger an automation on my HA. Below is the screenshot of the reaction but every time I hit the play button to test it nothing happens. I called the service locally on HA and it worked fine. MSR latest-22203-d7cd6357 and HA 2022.8.3. No errors in HASS logs or Reactor logs. 715cd920-effd-4d31-8ac3-ba34ef29185c-image.png
-
Hi!
In Home Assistant I sometimes uses the TTS, either to my Sonos or Google speakers. With reactor in Vera I also use TTS.
But in MSR I can't select the TTS-service. It's simply not there. Am I missing something, or is this the case, so far?
Thanks!
/Fanan -
I have the following rule:
Screenshot 2022-08-09 at 17.33.39.png
Use this to detect errors in Nibe uplink service, and every time updated data is fetched, a timestamp is stored. This triggered already yesterday, but re-triggered as I tried to manually recover this rule with a reset (hence there's no original "true as of xxx" time).
So as a clarification, service works now and timestamps are updated, but this rule does not "recover" (stays triggered / SET). Did also restart MSR during this situation, though it was not related to this.
The condition where there was no change (and rule was working correctly) lasted over 24 hours.
Running MSR 22179 on Synology Docker. Can PM relevant logs if needed.
-
I'd like to extract a specific part of a response to http request, in this case of link https://www.nibeuplink.com/Welcome#service_message. If there's something in "service_message" I'd store it & send using Telegram.
I reckon I'd have to use something similar as in this thread?
-
Deleted some entities from HA and added some new ones but MSR is still showing the old ones and not all of the new ones. I restarted MSR and it hasn't changed, is there anyway to manually discover new entities and delete the old ones? Most of the new entities have shown up but a few haven't, however none of the deleted entities were removed from MSR.
I checked the core.entity_registry in HA and none of the entities that are shown in MSR are there.
Edit: I see the delete option under the entities tab in MSR, is that the only way to delete them?
-
Hello all, I am finally ditching my Vera and moving to HA using a Zooz ZST10 Z wave stick. I have around 50 Z wave devices with a good mix of battery devices, locks, sensors and switches. The plan is to include all the AC powered devices first, starting from the ones closest to my Z wave stick then moving outwards. Once that is complete I will go back and include all battery powered devices in the same fashion.
My question is there any quick way to exclude all my Z wave devices from Vera, or should I just delete all devices without excluding them and factory reset each device before pairing to HA?
-
Just seen notification to Netatmo developers that the current password-based login is being disabled as from October.
Oath2 is now a requirement for apps needing access to Netatmo. This will require some changes to my venerable plug-in. I’m not sure how easy this will be with the current libraries in use.
Does anyone out there use the Netatmo plug-in?
Does anyone have any advice on using Oath2?
-
Successfully got MSR to run on a VM running Ubuntu 22.04 but am running into an issue with getting to run MSR as a service. Here is what my reactor.service file looks like below.
However when I go to run the service I see this error: reactor.service: Failed at step CHDIR spawning /usr/bin/node: No such file or directory. Checked and the node file exists in this directory. Kinda stuck at this point, probably a simple fix but I am way in over my head 😰
[Service] Type=simple User=armans2 WorkingDirectory=/home/reactor Environment=/home/reactor ExecStart=/usr/bin/node app -p Restart=on-failure RestartSec=5s -
Two stores apparently have inventory of RPI 4Bs with 2GB RAM. Get them while they last!
Raspberry Pi 4 model B - 2GB - RaspberryStore interadmin12 / 62.95 EUR Raspberry Pi 4 Model B 2GB RAM Raspberry Pi 4 Model B 2GB RAMBestel de nieuwe Raspberry Pi 4 B 2GB nu snel en voordelig bij Elektronicavoorjou.nl! - Raspberry Pi Boards, Behuizingen, Heatsinks, Accessoires & meer!
-
Hey crew,
I'm running into an issue where MSR's reactions aren't successfully running, and I can't figure out what's gone wrong.Backstory-- we had a big thunderstorm roll through the other day, we lost internet and the storm got bad so I unplugged most items in my homelab, including the Pi that's running MSR.
Now that everything is powered back up, the reactions aren't running correctly. Most of my MSR automations are to use motion sensors to turn lights on/off, and I immediately noticed that even when a motion sensor is tripped, the light doesn't turn on like it's supposed to.
I've tested a bunch of things to see what's broken, here's what I've observed:
-I can successfully flip lights on/off manually within Vera
-I can successfully flip lights on/off manually within MSR's Entities section
-the motion motion sensors are correctly reporting to Vera and MSR (I can see when they're sensing motion)
-the rules within MSR are working correctly, I can see when they flip to 'true' when I walk by a motion sensor
-I can successfully run the Reaction within MSR (by hitting the 'play' button)But for whatever reason, when everything needs to work together, it doesn't successfully run the action. IE: the motion sensor trips, reports it to MSR, I can see MSR going "true" but the light does not turn on. Open to any suggestions, thank you!
SYSTEM
Vera has all my devices
MSR is running bare metal on Rpi "Reactor (Multi-hub) stable-22004-6d6c6b7" -
Script to disable all the mios/vera proprietary program and broadcast its zwave and zigbee radio serial ports in your network so it can be picked up by another controller... For example z-way.
rafale77/Nuke-Vera rafale77/Nuke-VeraScript to neuter the vera and broadcast its zwave and zigbee serial ports - rafale77/Nuke-Vera
-
Apologies in advance, I expect I am going to make a total pig's ear of explaining, so please bear with me....
(and if it's in the manual, just tell me to read the manual)Going back to my heating scenario:
We have an alarm clock that goes off at a variable time.
We want the heating to go off at a time before that (1 hour)
so we have created the rule set as below:
Screenshot 2022-07-28 at 16.40.13.pngSo if current time is >= to the HeatTime, the first condition goes true.
The second condition is to ensure that nothing (tries to) turn(s) the heating off during that 1 hour window
The interval is there because in Reactor there was precisely that to (from memory) 'make sure the variables updated'
In the current state it kind of works. There is no Reset action, so the heat goes on once every 15 minutes during that hour.
In Reactor I didn't have to include the interval in the rule set. It was a stand alone rule as here:
Screenshot 2022-07-28 at 16.47.23.pngIf I move the Interval condition out of the rule set in MSR, things do not update as time changes (and the rule never sets)
So I guess the question I'm trying to ask it 'what causes expressions like
time() >= HeatTimeTo be evaluated, and is there a better way than I've done here?
Apologies again 😞
C
-
Hi
I’m trying out the Fitbit api, not only to extract some activity data for a potential plugin, but also to learn more about OAuth 2.0. More details can be found here..
Fitbit Development: Getting Started Fitbit Development: Getting StartedYou'll fit in here. Using JavaScript, CSS, and SVG, developers now have a fast, easy way to build apps and clock faces for Fitbit OS.
In addition to having a fitbit account, to get going with any integration, you need to register your app, via here..
LoginWith an app registered, I’ve called mine “VERA” , I’ve written chunks of Lua code to support the various steps, (completed manually) my goal now is to try and put them all together into functions to be called in sequence on my Vera and/or OpenLuup.
Where I’m getting stuck is with the authorisation code step, which Fitbit provides appended to the domain name I registered with them when registered my app ..
Here’s an example of a redirect URL that Fitbit will redirect the user too, with their associated authorisation code, which I need in the process later on to obtain the required access token. (More specific details are here - https://dev.fitbit.com/build/reference/web-api/developer-guide/authorization/ )
https://myapp.com/callback?code=d62d6f5bdc13df79d9a5f#_=_And it’s the d62d6f5bdc13df79d9a5f part of that new page/URL which I need..
How best do i capture/process the URL call Fitbit issues?
I assume this is where a luup.register_handler would come in, and I could register my Vera handle (using https ?, as that’s required by Fitbit) as the redirect domain/url e.g.
https://veraip:3480/data_request?id=lr_fitbit&So Fitbit would redirect to..
https://veraip:3480/data_request?id=lr_fitbit&/?code=d62d6f5bdc13df79d9a5f#_=_But that doesn’t seem to work..
Any suggestions on how to do this would be appreciated..
function FitbitRequestHandler(lul_request, lul_parameters, lul_outputformat) for k,v in pairs(lul_parameters) do luup.log ('fitbit_Handler: parameters are: '..tostring(k)..'='..tostring(v)) end if next(lul_parameters) == nil then luup.log("lul_parameters Table is empty") end local html = "</html><head>" .. "</head>" .. "<body>" .. "PRINTING" .. "\n" .. " lul_request: " .. tostring(lul_request) .. "\n" .. " lul_parameters: " .. tostring(lul_parameters) .. "\n" .. " lul_outputformat: " .. tostring(lul_outputformat) .. "\n" .. "</body></html>" return html, "text/html" end luup.register_handler("FitbitRequestHandler", "fitbit")Thanks is advance…
-
I've been running into an issue with a couple APIs wherein they return the error FetchError: network timeout....
A retry resolves but my ask here is around how I can monitor within MSR and trigger (at least) a notification if not a retry after a short delay.
-
I hope this is the correct forum – apologies if not!
I have a Raspberry Pi3 with a Razberry Z-Wave card installed. I have installed the Z-Way software and have successfully included a Fibaro Z-Wave switch on the Z-Wave network. I can toggle the switch on and off successfully from my laptop through port 8083 of the Raspberry Pi3.
On the same Raspberry Pi3 I have installed openLuup on which I have installed the Z-Way plugin. I can access this through port 3480 on the Raspberry Pi3 from my laptop.
Here is where I have come to a dead stop. How do I get access to the Fibaro Z-Wave switch from the openLuup application? I can find no documentation that tells me specifically how to do this.
Any help would be greatly appreciated.
_John.
-
Hi All -
I'm currently working through a slow migration from Vera to Home Assistant with MSR being a pivotal piece of the equation.
I have begun the effort of moving some ZWave devices as well (from Vera to HA). Unlike others that use Vera for the ZWave radio, I'm looking to completely remove it from my ecosystem, eventually.
My issue is I have some Vera Scenes that are designed to be manually executed by the Vera Mobile app. Examples: "Go to Sleep", "Panic - Lights On", etc (Wife Acceptance Factor)
I think MSR is the right place for any new "Scene" (including manual scenes); and from my reading, a Global Reaction makes sense.
Question 1: Can anyone recommend a way to execute a Global Reaction from a Vera scene? I've seen some examples of HTTP calls to MSR so I assume this is it (perhaps custom Luup which I know very little about).
Question 2: How can I (manually) execute this Reaction from Home Assistant? I'm slowly building out my custom Dashboard using "Mushroom".
Or, maybe there's a better way. Always open to constructive criticism.
Thanks.
-
I would like to extract the daily gas price from my fuel supplier's API. The http call is as follows: https://octopus.energy/api/v1/tracker/G-1R-SILVER-2017-1-M/daily/past/90/1/
I need to pick the current (i.e. today's) gas price. If I search through the text manually I can find today's data, in this case 2022-07-20.
Can I set MSR up to do a http request and then extract the "unit_rate" into a variable so that I can set another rule up to determine if it would be cheaper to heat my hot water using the immersion heater or gas (FYI my off peak electricity price is £0.075 per kwh). Any help or guidance as always is much appreciated.
I'm running MSR on raspberry PI 4 in docker version 22168
Thanks.
{ "date": "2022-07-20", "market_index": 62.8463, "cost": 15.094631164947945, "standing_charge": 15.0885, "unit_rate": 8.211, "usage": 0.0007467013698630137, "unit_charge": 0.0061311649479452055, "breakdown": { "unit_charge": { "Wholesale cost": 6.28463, "Environmental & social obligations": 0.0, "Delivery & networks": 0.9681, "100% green": 0.0, "Administration, financing & margin": 0.56727, "VAT": 0.391 },`
Best posts made by Alan_F
-
RE: Having trouble with http and basic auth
-
RE: Difference between two dates.
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.
-
RE: Vera firmware 7.32 beta
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.
-
RE: Suppressing alerts in HTTP Request actions
+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. -
RE: Having trouble with http and basic auth
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 UnauthorizedPrior 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.
-
RE: Notifications from Alerts
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.
-
RE: Notifications from Alerts
Just a note for posterity that alerts are now available as an entity as of version 21356.
-
RE: Opening curtains with a motion sensor but only once?
@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 trueThe next time the motion sensor trips before midnight the curtains will not open
-
RE: MQTT - add rules support ?
@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...
-
RE: General question: MSR and multiple HE hubs
They are not using the Hubitat mesh. They are completely separate.
Latest posts made by Alan_F
-
RE: Cheapest platform on which to run MSR
@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.
-
MSR/MQTT - detecting broker offline status
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?
-
RE: [Solved] Arm for Eastern Standard Time/Daylight Saving Time
@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.
-
RE: [Solved] Arm for Eastern Standard Time/Daylight Saving Time
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.
-
RE: [Solved] Reactor 22067 + Hubitat / InfluxDB feed storing wrong value then stopping on specific attributes
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.
-
RE: [Solved] Reactor 22067 + Hubitat / InfluxDB feed storing wrong value then stopping on specific attributes
@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.
-
[Solved] Reactor 22067 + Hubitat / InfluxDB feed storing wrong value then stopping on specific attributes
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.
-
RE: [SOLVED] Expressions not auto-updating when dependencies change (22022)
Option 2 seems like the way to go. I'll make that change and wait for nothing to happen
-
RE: [SOLVED] Expressions not auto-updating when dependencies change (22022)
@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?