-
In the background of other work, I've been putting together a build system for the OpenWrt version that Ezlo is using on the Plus. Job done. I can build pretty much any package, which may come in handy some day.
As a test of that, I thought, why not build nodejs... and you know where that leads, right?
It took some doing. There are a lot of dependencies, and the errors you get when the dependencies aren't met correctly can be cryptic and took quite a bit of research and experimentation to resolve... weeks, in fact, over a couple of hours here, a couple there.
But it's done and I now have Reactor running on an Ezlo Plus.
I'm not sure what the long term utility of this might be. Since the new Ezlo philosophy is to upgrade your system automatically on reboots, and so far the upgrades have wiped substantial parts of the file system in my experience, this could be a non-starter as a platform — you wouldn't want your automations to get blown off the machine every time Ezlo upgrades firmware (because you don't know when that's going to be, and Murphy says it will be while you are on vacation with no remote access). But, if there is some place it can be tucked away safely, or if, as probably should be demanded by the user community, updates become elective and user-driven, it actually makes a nice Pi-ish platform to run on.
On to the next skunkworks project...
-
Timestamps do not match the UI time or the system time:
[latest-21286]2021-10-16T03:10:43.922Z <Engine:INFO> Engine#1 master timer tick, local time "10/15/2021, 8:10:43 PM" (TZ offset -420 mins from UTC)I tried adding TZ to the docker container with "docker exec reactor apk add tzdata" but there was no change in log timestamps. I have the TZ in the compose file as:
environment: REACTOR_DATA_PREFIX: /var/reactor TZ: America/Los_AngelesThis does set the UI time correctly. The Reactor config is also set correctly:
location: city: "Los Angeles" -
I'd like to invoke in Reactor a Home Assistant service through the HA API. I use the following code in a vera plugin I wrote to send an HTTP request to Home Assistant to trigger an announcement on Alexa--using a Home Assistant Alexa integration that you can install through HACS.
myEchoDevice = "alexa_media_".. myEchoDevice myEchoMessage = table.concat(myEchoMessage) local request_body = json.encode {message = myEchoMessage, data = {["type"] = "announce",method = "all"}} local response_body = {} local theURL = 'http://'..HomeAssistantIP..':'..HomeAssistantPort..'/api/services/notify/'..myEchoDevice r, c, h = http.request { url = theURL, method = "POST", headers = { ["Content-Type"] = "application/json", ["Authorization"] = "Bearer ".. HomeAssistantToken, ["Content-Length"] = request_body:len() }, source = ltn12.source.string(request_body), sink = ltn12.sink.table(response_body) }I don't see the "notify" service in the HA attributes revealed by reactor. Is there a way to access the Home Assistant API through reactor, or do I need to use HTTP requests to initiate services.
-
Hi
I have some devices on my Vera Plus controller that sometimes change to say "Can't detect device".
I can clear those red banners that show up in the Vera UI7 web GUI, for a device by running some LUA code like this:
luup.set_failure(0, 331)Maybe I can use the new MSR matchEntities to find and detect any devices on Vera that have developed the "Can't detect device" error and then reset them. ?
I can currently manually specify a particular problem device in a ruleset trigger like this:
6f789006-ce19-4776-b3dd-290e28e84c8b-image.png
But if I could have a rule that automatically detects any device that develops this problem that would be better.
Thanks
-
Hi Patrick! @toggledbits
I don't remember before version 21277 receiving this kind of message.
dbea16f0-39f8-475a-bee8-8899069f2db3-image.png
This is in the log, this warning appears hundreds of times, every 1 second it repeats.
[latest-21281]2021-10-10T16:13:46.107Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-10T16:13:46.482Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...
[latest-21281]2021-10-10T16:13:46.835Z Rule:WARN Rule#rule-ku32lfti (Warning (93) Devices) update rate 61/min exceeds limit (60/min)! Logic loop? Throttling...As you can see, the rule that has generated this warning is run on demand at 10am, where the information is loaded into local variables, and then I use it to send the information by Telegram, only once a day.
5d55901a-bcbe-4cd6-8989-01d7a0ff9c67-image.png
I started using this matchEntities() instruction recently when it was made available, and I see you have been making recent adjustments. Wouldn't this situation of continuing to evaluate be related?
I will turn the rule off, so as not to generate this situation that surely damages the functioning of the MSR, and I look forward to your comments please.
Thanks
-
Hi!
- id: reactor_system enable: true implementation: SystemController name: Reactor System config: # # The update_interval can be set lower for more frequent updates. The default is 60 # seconds, which is probably fine for most cases, but causes the 15-second load av- # erage to be inaccurate (the first value in reactor_system.system_load). If you # don't care about the 15-second load average, then the default 60 seconds is fine. # This value is expressed in milliseconds. update_interval: 60000 locale: sv-SE #
I would like to try out the swedish translation (thanks @Crille ). I have tried to edit my reactor.yaml file in many ways, but the translation don't show up. I have done a browser hard refresh every time. Where do I go wrong? Here's my latest try:What's the correct syntax, placement and intendention?
Thanks!
/Fanan -
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here.
Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed. -
Got a warning that "Rule is being throttled because its update rate exceeds 60 updates per minute. Check for logic errors that may be causing an evaluation loop, or devices that are "flapping".
Device in question here is Aeotec Smart Switch 6 connected to Vera Plus, and its configuration is below:
Screenshot 2021-08-31 at 13.13.22.png
Shouldn't be an evaluation loop as the rule is very simple (two AND'ed conditions where the first checks whether alarm state is "disarmed" and the second if smart switch power switch state is false).
Noticed though at the time of warning that wattage measured/reported was changing quite rapidly, so even though wattage was not used in the rule, could that be the reason for throttling? If so, is there anything else that could be done other than raising minimum change values in device configuration? Would like to retain sensitivity for other purposes.
-
Just noticed that when trying to reorder some expressions, e.g. move the most recent one from the bottom of the list to the first, this new order didn't "stick".
At first yes, but when visiting some other menus (obviously saving before that) and then coming back, the moved item was in its original position (in the end of the list).
I currently have 29 global expressions (which may or may not have some relevance to this problem). Using build 21281 on linux.
Can log a PR with logs, if this seems hard to reproduce.
-
Hey crew, I followed the tutorial to get MSR installed on Rasbperry Pi (bare metal). Just having a little trouble getting Vera to connect to it.
I'm getting error messages-- I searched in the forum and didn't see other people running into these messages. Here are the two main errors I've been getting...
2021-09-21T01:30:36.477Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187836460 failed, reason: socket hang upand
2021-09-21T01:26:08.296Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187568275 failed, reason: connect ECONNREFUSED 10.0.0.141:3480I'm sure it'll be an easy fix, but truthfully I'm stumped here and would love any advice. Thank you!
-
@toggledbits I've done a (test) Swedish translation for MSR, I don't want/need a translated version, but I had the time and perhaps some future users would find it useful 🙂
I noticed it's a bit early in the process to go live with systemwide localizations so no github in place yet, do you want input on this now or should we wait a few releases? considering it may be low priority issues.
If so, do you want feedback here or in mantis? -
Let's say I have an array like the one below:
["vera>device_216","vera>device_235","vera>device_241"]How do I remove "vera>device_235" out of it?
Alternatively, when filtering entities:
each id in dynamic_array: getEntity( id ).attributes.x_vera_svc_micasaverde_com_HaDevice1?.CommFailure == 1 ? id : nullHow could I exclude certain id from the array that is produced?
-
I have some battery powered sensors that doesn't report battery level and thought it would be nice if can make MSR to send me a notification if a sensor value doesn't change for 24h.
I tried to make a rule that monitored if a temperature value NOT changes, but in this setup I couldn't choose Sustained For as I expected.
Any way around this?
Any reason that Sustained For can't be used when monitoring a value Change? -
@toggledbits Today I got a false positive from Reactor saying my Ezlo Plus was offline, a restart of Reactor solved it.
2021-10-01T06:32:29.441Z <EzloController:ERR> EzloController#ezlo ws_message handler failed: RangeError: Maximum call stack size exceeded 2021-10-01T06:32:29.441Z <EzloController:CRIT> RangeError: Maximum call stack size exceeded RangeError: Maximum call stack size exceeded at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1134:127) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) at EzloController._now.ws_message [as refreshTime] (/home/user/reactor/server/lib/EzloController.js:1138:54) 2021-10-01T06:32:38.985Z <EzloController:ERR> EzloController#ezlo request "17c3a8dccaf" (hub.info.get) failed: TimedPromise timeout 2021-10-01T06:32:38.985Z <EzloController:ERR> EzloController#ezlo failed to complete inventory: TimedPromise timeout 2021-10-01T06:32:38.985Z <EzloController:CRIT> !TimedPromise timeout 2021-10-01T06:32:38.988Z <EzloController:NOTICE> EzloController#ezlo connection closed: 1002
This was found in the log before the restart:Reactor latest-21270-48528ec, updated to latest-21270-46679ac just now.
-
@toggledbits I followed to the letter your excellent step-by-step guide on launching a Docker container from the image I fetched from PR #58 this morning.
All proceeded swimmingly – folder creation, image upload, settings & parameters, etc. – until the moment of actual Launch.
Whereupon, Docker threw up the following on-screen "Stopped Unexpectedly" warning (which repeated every 30 seconds or so until I Stop'ped the container from running/restarting):
docker_msr_stopped.pngConcurrently, every attempt to access http://<mySynNAS_IP>:8111/ resulted in a "This site can't be reached" error page in Chrome (under Windows, mind you).
Immediately, I took the liberty of inspecting and Export'ing the logfile (Container ► Details ► Log) as an HTML file, which I attach below (oops, no attachment feature in this forum, so here is the direct link) for your inspection.
Hope you find some clues, because I'm not at all sure where things went wrong. (The only facet of setup where I expressly deviated from your typed notes involved creating a "Shared" (i.e. top-level, rather than under /home) folder called "Reactor" with r/w access, under which I created a subfolder named "Data", to which I pointed /var/reactor during container creation.)
Excellent write-up and thanks for the chance to test this out!!
LibraFOLLOW-UP NOTES
I do see where Container ► Edit ► Environment ► variable PATH has a value of "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" which strikes me as odd, but maybe that's normal nomenclature? (By contract, Windows and DOS always use semicolons, not colons, to separate PATH variable entries.)RESOLVED
Noting that the Log displayed an error message related to /var/reactor/config, I went and created a folder named 'config' (all lowercase) under the NAS's top-level Reactor\Data folder, then restarted the container. It's running fine now, and I'm able to access the :8111 interface for the first time.
Log ► "Configuration path: /var/reactor/config resolved /var/reactor/config"SUGGEST
Please add explicit declaration in your How-To regarding the need for a /config underneath the data folder. -
Hi, I was trying to setup influxdb for MSR and on my Synology Nas, docker installation, I started with Influxdb 2.0.
influxdb: api_version: 2 ssl: false host: 10.0.0.11 port: 8086 token: Your HomeAssistant - Write token organization: Home bucket: HomeAssistant
Now seems it is very different from 1.x.
Databases don't exist anymore, they are named "buckets" now and there are token values.
Looking around, I found something on HA like this in "configuration.yaml" file.I don't use HA, just starting to bring devices on ezlo plus. Does MSR support this version Influxdb 2.0? or better to re-install 1.x?
Thanks in advance
-
I did a fresh install of MSR yesterday and noticed that the latest docker image was not pulling down. I had to use the CLI command "docker-compose pull MSR" where "MSR" is the service name I gave to the container in docker compose. After pulling the image, most everything worked as expected and the localization bug I saw was resolved. I've seen this type of update behavior before in other containers-- usually when the docker tags are not updated, but it could be something wacky on my end as well.
I also saw a small bug in the config file that I tried to post on Mantis, but I could not log in. Are you using the bug tracker, or do you prefer forum posts?
-
Hi everyone
I'm about to set up notifications from MSR and would like input on what works best.
Quick and reliable delivery to Android devices is the goal.(Tried to set up pushover last night, but probably missed something because it doesn't work. Succeed thru homeassistant, but not with MSR.)
Is pushover worth its money?
what do you use and why?Greatly appreciate your thoughts 🙂
-
I'm struggling to get MSR working in my QNAP (TS-321P). I am obviously not doing something correct in the setup, but cannot work out what. When I select 'Start' a second or so later the container stops. I get the following message in the container station - container tab 'standard_init_linux.go:219: exec user process caused: exec format error'. Assistance would be very much appreciated!
-
Has anyone played with the LIFX API thru Reactor? https://api.developer.lifx.com/docs/introduction is their info. I see a lot of curl noted and, admittedly, my API-foo ignorance is only surpassed by my Expressions ignorance.
I know the API call requires authentication, just having a hard time formatting what goes where in the Reactor fields to facilitate this.
My reason for tapping their API is that instructions sent from Reactor to the actual bulbs are hit or miss as far as what the results show. Thought was that, perhaps, calling their API may improve this.
Trouble connecting Vera to MSR
-
Hey crew, I followed the tutorial to get MSR installed on Rasbperry Pi (bare metal). Just having a little trouble getting Vera to connect to it.
I'm getting error messages-- I searched in the forum and didn't see other people running into these messages. Here are the two main errors I've been getting...
2021-09-21T01:30:36.477Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187836460 failed, reason: socket hang upand
2021-09-21T01:26:08.296Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187568275 failed, reason: connect ECONNREFUSED 10.0.0.141:3480I'm sure it'll be an easy fix, but truthfully I'm stumped here and would love any advice. Thank you!
-
That looks like your Vera reloading...a lot. I doubt this is caused by MSR. I would stop MSR or disable the integration by setting
enabledtofalsein thereactor.yamlconfig for your Vera, and figure out why your Vera isn't happy.Troubleshooting steps would be the usual for a Vera that's reloading a lot: check for ZWave devices (particularly battery-operated) that are having trouble communicating, and if all that's fine, start looking at your plugins.
-
@toggledbits Oh yikes. I will look into this. Thank you!
-
@toggledbits Do you mind helping me understand why the "socket hang up" & "ECONNREFUSED" messages mean that Vera is reloading a lot?
-
The ECONNREFUSED means that your Vera is not accepting connections. This happens during reloads, when the box is up and running but LuaUPnP is not ready to answer requests. It could also mean you have the wrong IP address configured, or the IP is not reachable on the network segment you are on, but I'm assuming you know the correct IP of the box and have configured it correctly, and the other message suggests something is reachable at the IP and port given (and the port is very unusual and specific to Vera).
The "socket hang up" means that the LuaUPnP engine accepted the connection but the connection was terminated before the request could be sent, or terminated with no response data -- the server/Vera closed the connection without saying anything, or didn't say anything within the connection timeout period, although timeouts are usually more definitive and reported as such.
I'm assuming you're seeing a lot of these, and that's why you posted.
-
@apocalypsehobby You might also have authentication on. Check in the highlit file below to make sure "auth" is commented out --- like you see in the subsequent screenshot. The file is located in the etc folder on the vera:
you also need to make the same adjustment in the same name file stored in the lighttpd folder that is under etc/:
-
Thank you both. @Buxton I followed these directions and commented out "auth" in both files, restarted Vera, still got the same error messages.
What's strange is-- I took one of the request URLs (like http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632187568275) and pasted it into my laptop's web browser, and I got a huge output file. So it seems like Vera is working.
Maybe it's a network configuration problem like you suggested, @toggledbits ? So I went to my Raspberry Pi that's running MSR, and I used wget then it successfully downloaded the output file to the pi as well. So I'm not sure why it's not working within MSR!
-
Let's go back to a previous question... are you getting a ton of these, or just occasionally?
-
@toggledbits A ton
pi@MSR-raspberrypi:~/reactor $ node app.js basedir /home/pi/reactor confdir /home/pi/reactor/config datadir /home/pi/reactor/storage logsdir /home/pi/reactor/logs plugindir /home/pi/reactor/ext module.paths [ '/home/pi/reactor/node_modules', '/home/pi/node_modules', '/home/node_modules', '/node_modules' ] NODE_PATH undefined 2021-09-25T18:29:17.047Z <app:null> Reactor "1.0.1-21243-83a87ba" starting on v14.17.6 2021-09-25T18:29:17.051Z <app:INFO> Process ID 3194; platform linux/arm #1449 SMP Wed Aug 25 15:00:01 BST 2021; locale [ "en-GB", "UTF-8" ] 2021-09-25T18:29:17.053Z <app:INFO> Basedir /home/pi/reactor; data in /home/pi/reactor/storage 2021-09-25T18:29:17.054Z <app:INFO> NODE_PATH (undefined); module paths [ "/home/pi/reactor/node_modules", "/home/pi/node_modules", "/home/node_modules", "/node_modules" ] 2021-09-25T18:29:17.245Z <Plugin:null> Module Plugin v21173 2021-09-25T18:29:17.270Z <default:INFO> Module Entity v21177 2021-09-25T18:29:17.280Z <Controller:null> Module Controller v21226 2021-09-25T18:29:17.281Z <default:null> Module Structure v21229 2021-09-25T18:29:17.303Z <default:null> Module Ruleset v21096 2021-09-25T18:29:17.304Z <default:null> Module Rulesets v21096 2021-09-25T18:29:17.373Z <default:null> Module Rule v21224 2021-09-25T18:29:17.388Z <default:null> Module Engine v21213 2021-09-25T18:29:17.390Z <default:null> Module httpapi v21238 2021-09-25T18:29:17.396Z <default:null> Module httpproxy v21054 2021-09-25T18:29:17.443Z <default:null> Module wsapi v21196 2021-09-25T18:29:17.447Z <app:NOTICE> Starting Structure... 2021-09-25T18:29:17.455Z <default:NOTICE> Structure#1 plugin ID influx disabled; skipping 2021-09-25T18:29:17.459Z <default:INFO> Structure#1 starting controller interface vera (VeraController) 2021-09-25T18:29:17.470Z <default:INFO> Structure#1 starting controller interface hass (HassController) 2021-09-25T18:29:17.473Z <default:INFO> Structure#1 starting controller interface reactor_system (SystemController) 2021-09-25T18:29:17.614Z <default:null> Module VeraController v21236 2021-09-25T18:29:17.625Z <default:null> Module HassController v21243 2021-09-25T18:29:17.630Z <default:null> Module SystemController v21102 2021-09-25T18:29:17.641Z <VeraController:NOTICE> VeraController#vera starting 2021-09-25T18:29:17.809Z <VeraController:INFO> VeraController#vera loaded mapping ver 21236 rev 1 format 1 notice 2021-09-25T18:29:17.812Z <VeraController:INFO> VeraController: deviceclass vera_system_object capability sys_system does not provide attribute state 2021-09-25T18:29:17.926Z <HassController:INFO> HassController#hass device mapping data loaded; checking... 2021-09-25T18:29:17.997Z <HassController:NOTICE> HassController#hass attempting reconnection to ws://10.0.0.108:8123/api/websocket 2021-09-25T18:29:18.002Z <HassController:NOTICE> HassController#hass connecting via WS to ws://10.0.0.108:8123/api/websocket 2021-09-25T18:29:18.018Z <default:NOTICE> Controller SystemController#reactor_system is now online. 2021-09-25T18:29:18.192Z <app:INFO> Structure running; pausing for controllers' initial ready 2021-09-25T18:29:18.261Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594557823 failed, reason: socket hang up 2021-09-25T18:29:18.285Z <HassController:NOTICE> HassController#hass connected, starting protocol 2021-09-25T18:29:18.304Z <HassController:INFO> HassController#hass successful authentication with ws://10.0.0.108:8123; fetching initial data... 2021-09-25T18:29:18.317Z <HassController:INFO> HassController#hass Hass reports version "2021.8.6" location Home timezone America/Detroit state RUNNING safe_mode false 2021-09-25T18:29:18.553Z <HassController:NOTICE> Controller HassController#hass is now online. 2021-09-25T18:29:23.290Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594563265 failed, reason: socket hang up 2021-09-25T18:29:28.312Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594568291 failed, reason: socket hang up 2021-09-25T18:29:33.339Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594573317 failed, reason: socket hang up 2021-09-25T18:29:39.363Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594579344 failed, reason: socket hang up 2021-09-25T18:29:46.392Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594586368 failed, reason: socket hang up 2021-09-25T18:29:54.420Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594594399 failed, reason: socket hang up 2021-09-25T18:30:03.448Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594603429 failed, reason: socket hang up 2021-09-25T18:30:13.468Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594613450 failed, reason: socket hang up 2021-09-25T18:30:18.265Z <app:NOTICE> Starting Reaction Engine... 2021-09-25T18:30:18.269Z <Engine:INFO> Reaction Engine starting 2021-09-25T18:30:18.273Z <Engine:INFO> Checking rule sets... 2021-09-25T18:30:18.285Z <Engine:INFO> Checking rules... 2021-09-25T18:30:18.287Z <Engine:INFO> Data check complete; no corrections. 2021-09-25T18:30:18.296Z <Engine:NOTICE> Reaction Engine running! 2021-09-25T18:30:18.297Z <app:NOTICE> Starting HTTP server and API... 2021-09-25T18:30:18.314Z <app:NOTICE> Startup complete 2021-09-25T18:30:18.323Z <app:NOTICE> HTTP API v1 21238 base URL http://10.0.0.5:8111; listening 2021-09-25T18:30:18.362Z <app:NOTICE> HTTP server running; registering proxy endpoints. 2021-09-25T18:30:18.365Z <app:NOTICE> Starting WSAPI... 2021-09-25T18:30:18.368Z <app:NOTICE> wsapi: starting version 21196 2021-09-25T18:30:18.405Z <Engine:INFO> Engine#1 master timer tick, local time "25/09/2021, 14:30:18" (TZ offset -240 mins from UTC) 2021-09-25T18:30:18.687Z <app:INFO> wsapi: connection from ::ffff:10.0.0.91 2021-09-25T18:30:24.490Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594624469 failed, reason: socket hang up 2021-09-25T18:30:36.518Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594636500 failed, reason: socket hang up 2021-09-25T18:30:49.536Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594649518 failed, reason: socket hang up 2021-09-25T18:31:03.567Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594663549 failed, reason: socket hang up 2021-09-25T18:31:18.580Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594678567 failed, reason: socket hang up 2021-09-25T18:31:34.607Z <VeraController:ERR> VeraController#vera update request failed: FetchError: request to http://10.0.0.141:3480/data_request?id=user_data&ns=1&Timeout=15&output_format=json&_r=1632594694590 failed, reason: socket hang up -
What version of Vera firmware are you running? What are the specs of the Pi?
pasted it into my laptop's web browser, and I got a huge output file. So it seems like Vera is working.
How long did it take to get the response?
-
@toggledbits
Vera Firmware: 1.7.5186 (7.31)
Pi: Raspberry Pi 3 Model B Plus Rev 1.3, and the Debian version is 10.10The response was immediate from the web browser, and from when I used wget within the Pi.
-
I have it running on both a 1GB 3B+ and a 4GB 4, but under Raspberry Pi OS/Raspian. I'd suggest trying that next.
-
@toggledbits Sorry, I should have been more specific, it’s running Raspberry Pi OS Lite. Are you saying it should be the regular Raspberry Pi OS?
-
OK. The version of nodejs you've got running isn't the one installed by the install script... did you run the install script? It will still let you use that version, that "should not" be a/the problem, but the script does other things... installs dependencies, certain versions... should not be run as root or under
su/sudo... did all that happen? -
@toggledbits Oh jeez, I followed the wrong set of instructions from the get-go. When you asked about the install script, I retraced my steps and realized what happened.
I followed the "Linux (various) Bare Metal" instructions because I did not read that the 4B instructions also worked for the 3B+.
So I just started fresh and followed the correct instructions, and everything seems to be working. Thank you for your help!
-
Sounds good. Still leaves me wondering what was going on, because the bare metal steps basically take you in the same direction as the installer (and the reverse is also true — you could run the Pi install script on pretty much any Linux box and probably get a valid install). In the background, I also brought up a 3B+ on RaspiOS and did a bare metal install with node 14.17.6 as you had, and it worked fine. So, not sure what may have gone sideways with your original install, but I'm glad the script straightened it out.
Did you let the install script install node 14.15, or did you let it go ahead with the 14.17 previously installed? That would narrow down some variables.
-
I just let it run with the 14.17