No, I really don't think you need it.
For some reason, though, I have one rpi that if I don't use it, it gives me the old "sudo: no tty present and no askpass program specified" error.
Not sure why, but I am sure that specifying -t works around it. Probably a band-aid more than a real fix, though, admittedly.
So, you're right. Probably better to leave -t off.
Got it running now, so it should be done in about 9 hours. So much more convenient than shutting down my Pi for 3-4 hours.
As i read this, I had this picture in my head lol
I have to look into these backup processes, I'd hate to lose all this time and effort already put into NR
How large is your SD card? Backing up a 16 GB eMMC takes 30 minutes on my Odroid XU4.
Well, you eMMC gets a much faster transfer rate than the EXTREMELY slow USB 2.0 bus in my RPi 3. My much faster Pi 4 is a media center box. You know, where speed really matters. 
And the USB bus on the Pi 3 is shared with wifi and eth and this box is running my MotionEye server, so it's receiving two camera streams. According to dd's "progress" update, right now it is copying at 537 kb/s, so it's down to only 8 1/4 hours. It started at 350 so it's getting faster and faster! LOL
Same here. When backing up over wifi it is abysmally slow on the rpi 3s. But it finishes eventually.
I am having trouble with multiple motion sensors. How do I get, using two motion sensors, to turn on a device if either is active (easy) but turn off only if both are inactive? Here is a sample of what I am using now:
Problem is if either one turns inactive, the turn-off timer starts, not when both are inactive.
Here's one way to do it:
Basically use two sequential function nodes to test whether the status of the motion sensor is inactive. And proceed to turn off the light only if both are inactive ....
[
{
"id": "8bb772f6.f415c8",
"type": "switch",
"z": "35026d62.1be99a",
"name": "inactive",
"property": "payload.value",
"propertyType": "msg",
"rules": [
{
"t": "eq",
"v": "inactive",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 1,
"x": 690,
"y": 1580,
"wires": [
[
"31cfcd42.d21d6a"
]
]
},
{
"id": "6d7c6df3.502094",
"type": "hubitat device",
"z": "35026d62.1be99a",
"name": "Motion - Closet",
"server": "a22e0ea9.276dc8",
"deviceId": "230",
"attribute": "motion",
"sendEvent": true,
"x": 502,
"y": 1579,
"wires": [
[
"8bb772f6.f415c8"
]
]
},
{
"id": "31cfcd42.d21d6a",
"type": "function",
"z": "35026d62.1be99a",
"name": "motion status",
"func": "msg.attribute = \"motion\"\nreturn msg;\n",
"outputs": 1,
"noerr": 0,
"x": 300,
"y": 1660,
"wires": [
[
"457b158e.2f122c"
]
]
},
{
"id": "645b3a38.e1cc7c",
"type": "function",
"z": "35026d62.1be99a",
"name": "motion status",
"func": "msg.attribute = \"motion\"\nreturn msg;\n",
"outputs": 1,
"noerr": 0,
"x": 300,
"y": 1580,
"wires": [
[
"6d7c6df3.502094"
]
]
},
{
"id": "457b158e.2f122c",
"type": "hubitat device",
"z": "35026d62.1be99a",
"name": "Motion - Guest Bedroom",
"server": "a22e0ea9.276dc8",
"deviceId": "322",
"attribute": "motion",
"sendEvent": true,
"x": 532,
"y": 1659,
"wires": [
[
"e5c16d4b.50ab"
]
]
},
{
"id": "8e191378.f3ab08",
"type": "stoptimer",
"z": "35026d62.1be99a",
"duration": "5",
"units": "Minute",
"payloadtype": "num",
"payloadval": "0",
"name": "",
"x": 640,
"y": 1500,
"wires": [
[
"645b3a38.e1cc7c"
],
[]
]
},
{
"id": "e5c16d4b.50ab",
"type": "switch",
"z": "35026d62.1be99a",
"name": "inactive",
"property": "payload.value",
"propertyType": "msg",
"rules": [
{
"t": "eq",
"v": "inactive",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 1,
"x": 750,
"y": 1660,
"wires": [
[
"13151626.7ecfb2"
]
]
},
{
"id": "1d349c90.cfc393",
"type": "switch",
"z": "35026d62.1be99a",
"name": "active/inactive",
"property": "payload.value",
"propertyType": "msg",
"rules": [
{
"t": "eq",
"v": "active",
"vt": "str"
},
{
"t": "eq",
"v": "inactive",
"vt": "str"
}
],
"checkall": "true",
"repair": false,
"outputs": 2,
"x": 452,
"y": 1425,
"wires": [
[
"7c3773e0.664dc4",
"6ba6066f.baa66"
],
[
"8e191378.f3ab08"
]
]
},
{
"id": "6ba6066f.baa66",
"type": "change",
"z": "35026d62.1be99a",
"name": "stop",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "STOP",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 450,
"y": 1500,
"wires": [
[
"8e191378.f3ab08"
]
]
},
{
"id": "13151626.7ecfb2",
"type": "change",
"z": "35026d62.1be99a",
"name": "lutron 0",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "0",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 900,
"y": 1600,
"wires": [
[
"904de033.31018"
]
]
},
{
"id": "8605e032.a372d",
"type": "hubitat device",
"z": "35026d62.1be99a",
"name": "Motion - Guest Bedroom",
"server": "a22e0ea9.276dc8",
"deviceId": "322",
"attribute": "motion",
"sendEvent": true,
"x": 208,
"y": 1400,
"wires": [
[
"1d349c90.cfc393"
]
]
},
{
"id": "bb03de87.f27508",
"type": "hubitat device",
"z": "35026d62.1be99a",
"name": "Motion - Closet",
"server": "a22e0ea9.276dc8",
"deviceId": "230",
"attribute": "motion",
"sendEvent": true,
"x": 240,
"y": 1460,
"wires": [
[
"1d349c90.cfc393"
]
]
},
{
"id": "7c3773e0.664dc4",
"type": "change",
"z": "35026d62.1be99a",
"name": "lutron 100",
"rules": [
{
"t": "set",
"p": "payload",
"pt": "msg",
"to": "100",
"tot": "str"
}
],
"action": "",
"property": "",
"from": "",
"to": "",
"reg": false,
"x": 660,
"y": 1420,
"wires": [
[
"904de033.31018"
]
]
},
{
"id": "904de033.31018",
"type": "lutron-control",
"z": "35026d62.1be99a",
"confignode": "a09cd867.559bd8",
"name": "Guest Bedroom",
"x": 980,
"y": 1480,
"wires": []
},
{
"id": "a22e0ea9.276dc8",
"type": "hubitat config",
"z": "",
"name": "HubitatM",
"usetls": false,
"host": "192.168.1.46",
"port": "80",
"token": "496f7f11-256d-44c9-99c6-4ed460d3efb0",
"appId": "1522",
"nodeRedServer": "http://192.168.1.4:1880",
"webhookPath": "/hubitat/webhook"
},
{
"id": "a09cd867.559bd8",
"type": "lutron-config",
"z": "",
"name": "Caseta Pro",
"ipaddress": "192.168.1.32",
"deviceMap": {
"Kitchen Wall": "2",
"Kitchen Tube": "3",
"Hallway": "4",
"Hallway Down Pico": "5",
"Bar": "7",
"Fireplace": "8",
"Dining": "9",
"Dining Pico": "10",
"Bar Pico": "11",
"Guest Bedroom": "12",
"Guest Bedroom Pico": "13",
"Kitchen Pico": "14",
"Catroom": "15",
"Catroom PIco": "16",
"Bedroom": "17",
"Bedroom PIco": "18",
"Hallway Up Pico": "6",
"ALL": "0"
}
}
]
I get it - evaluate after the timer runs.
Edit: sometimes one does not see the trees when looking through the forest, I just had to change the "a-z" dropdown to "msg"... duh! Sorry, it was a long long day yesterday
This is a general question but I'm just going to use an exact example to demonstrate:
The documentation for alexa-remote2 is "lacking" for a nicer term, how do I kind of deconstruct the node to try to figure out what I could possibly pass for a message/payload to set that search string on the fly.
Looking at the HTML of the node doesn't reveal anything
Going to the source code shows this:
It sure seems like the JS is looking for a message formatted like:
msg = { payload: { search: "Boards of Canada" } }
But that just results in:
Tips? Tricks? Advice?
I don’t use it and haven’t looked into the code my self, but the screenshot above of the code shows a “case ‘music’:” before it starts the search. In what variable is that switch/case done? I bet that you have to set a second parameter in your payload to tell Amazon that you want to search for music.
Overall my question is more of a “generic question of how to discover what one can pass to a node when the documentation is sparse”
It could be any node, I just provided an example of what I mean, so the fact one don’t use this exact node really shouldn’t be a factor. What does matter is if someone has experience reverse engineering some of this stuff
As for the example, the drop down in the the 1st screenshot drives thee case statement In the 2nd shot to get into that “music” node and then it’s pretty clear it’s giving provisions to read the search value from the payload, but that no workie
Only the code will tell you what you can and can't do if there is no documentation... Or finding examples where others used it online... There is really nothing else...
Yup, I get that!
Was asking for advice on how to narrow it down
Ok..... I looked at the code quickly.... Here is how I tackle those kinds of issues...
I usually add some logging statements in the code to see what is going on.
The modules are installed ~/.node-red/node-modules
In your case I would modify the file ~/.node-red/node-modulesnode-red-contrib-alexa-remote2/blob/master/nodes/alexa-remote-routine.js
and add the following statement below the line "const evaluated = tools.nodeEvaluateProperties(RED, this, msg, this.routineNode);"
node.log(`evaluated: ${JSON.stringify(evaluated)} msg: ${JSON.stringify(msg)}`);
I would then restart node-red and try my sequence again while looking at the node-red log output. This would reveal what the properties are that are passed for the routine. look especially at the values for "evaluated" as that is what is later on used by the plugin.
Just go to my next post after that one. There is a picture of the sequence and the code for it.
Does this work as intended for you? Reason I ask is I've just copied your logic flow and tried it on my system and when the last motion sensor in the flow (in your example the bottom "Motion - Guest Bedroom") goes inactive it passes inactive into the flow, regardless of the timer still running, and turns the light off.
Am I missing something? I've been wrestling with the multiple motion sensor problem for a bit and haven't come up with an elegant solution yet. I tried using Hubitat's Motion Zone app and using the resultant aggregated sensor, but I'm trying to find a way to do it all in NR.
I don't use that exact flow, but one very similar to it, which checks the status of a motion sensor (inactive) and a contact sensor (closed). And that flow certainly works.
@Geoff_T
EDIT: Found the error in the flow that I pasted. Send Events needs to be unchecked!!
That did it! Thanks, it works great now.
Download the Hubitat app
