Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: Possible to control command/device nodes via code? #10

Open
BladeRunner68 opened this issue Nov 6, 2017 · 14 comments
Open

Q: Possible to control command/device nodes via code? #10

BladeRunner68 opened this issue Nov 6, 2017 · 14 comments
Assignees

Comments

@BladeRunner68
Copy link

Is it possible we can provide the device and command via msg properties (and thus via code) rather than hardcoding the command and (hopefully forthcoming device) node with the activities/commands?

@skavan
Copy link

skavan commented Jan 31, 2018

+1

@skavan
Copy link

skavan commented Jan 31, 2018

Could it be as simple as the if statement inserted below? i.e. if the inbound message has a json payload with a command property, copy the command, type and deviceId property to the action object.
I have no idea how to make and commit these changes -- but this would be hugely useful!
Inbound Message:
{"command":"Stop","type":"IRCommand","deviceId":"49319863"}

node.on('input', function (msg) {
    try {
      msg.payload = JSON.parse(msg.payload)
      if (msg.payload.command || false) {
            action.command = msg.payload.command;
            action.type = msg.payload.type;
            action.deviceId = msg.payload.deviceId;
            }
    } catch (err) {

    }

@skavan
Copy link

skavan commented Jan 31, 2018

I have it working locally, with these changes in harmony.js. The updated node will accept either a string or JSON payload that looks like this:
{"command":"Stop","type":"IRCommand","deviceId":"49319863"}
Now if we could have a node that listed all available commands for a device and simply allowed an input of "stop" or whatever, and then pushed a message, that would be perfect!

  node.on('input', function (msg) {
      try {
    let injectCommand;
    switch (typeof msg.payload) {
		    case 'string':
		    injectCommand = JSON.parse(msg.payload);
		    break;
		    case 'object':
		    injectCommand = msg.payload;
  			    break;
		    default:
  			    msg.payload = JSON.parse(msg.payload);
    }
    if (injectCommand.command || false){
    	    //node.warn(action);
	    action = JSON.stringify(injectCommand);
	    action = action.replace(/:\s*/g, "::");
	    //node.warn(action);
	    }
      } catch (err) {

      }

@Aietes
Copy link
Owner

Aietes commented Aug 15, 2018

I can implement the possibility to provide a command as stanza via msg.payload, it would be hard however to hand in a command like described above. It would require to look up a command by name, on the other hand you assume the device is identified by ID.

@AirBorne04
Copy link
Contributor

@BladeRunner68 and @skavan can you explain the use case, why you would want to do that?

@Aietes
Copy link
Owner

Aietes commented Aug 23, 2018

When use cases are available, we'll reconsider this. Closing for now.

@Aietes Aietes closed this as completed Aug 23, 2018
@BladeRunner68
Copy link
Author

my suggestion was added in Nov 2017 and the world has moved on now. :)

@skavan
Copy link

skavan commented Aug 23, 2018

So...here's an example. Hope it makes sense. It's sometimes hard to describe these things.

  1. The current use case is all about controlling one or more harmony hub's via activities or device commands. But each activity or device command requires and instance of the command node.
    Here is a trivial example that shows a simplified d-pad for a device and a single activity.
    image
    This starts to get messy fast, the more "buttons" one adds, and the more devices one wants to control.

  2. In my use case, I have a whole house control system using an Android front end gui (the home remote) and alexa. Events are triggered by mqtt messages such as {"room": "living room", "device":"tv", "command": "menu"}. These mqtt messages are directed to the appropriate flow (one flow per device).
    I have generic flows for ip controlled devices, z-wave devices etc.. I use harmony hubs for devices I can't control with my generic flows. For example, an IR controlled AC unit, an IR controlled projector, an IR controlled cable box. If I was using a harmony hub for everything, then I could move programming into Activities in the hub....but even then - I would much rather have node-red be the state master and use the hub's as relatively dumb room controllers.

If I could pass a json payload to a variant of your command node, called for example H device, and in that payload specify a command, such as {"command":"menu"} and optionally a deviceId, such as {"deviceId": "25252525"}, then I could use a single H device for all commands to that device. The H device would allow the designer to select an harmony device from a specified hub - and inspect the ID's of all devices on that hub. It would also display the commands available for the chosen device.

If H device received, {"command":"menu"}, it would simply send that command to the pre-selected device in the node. If it received {"command":"menu", "deviceId": "3737373737"} it would ignore the preselected device and use the passed in Id. Harmony does a pretty good job of "Harmonizing" device commands, but if necessary, an intermediate "change" or "function" node could easily map an MQTT message of "on" to "ON", for example.
All the complexity of #1 now resolves to:
image
...and the only thing that changes when adding new device support (in a new flow), are the settings in H device (Hub and Device Selection) and possibly, the mapping transform node.

The only "issues" with this approach are the device command discovery and possible mapping needs.
But node-red makes light work of this. In fact, I have written a small json based map definition file for each device (whether it's ip based, harmony based etc..), and the only difference between my ip device flows and my harmony device flows is the ip node vs the harmony node.

Here;s an example - which looks much more complicated than it actually is -- using my own hack of your code. This flow controls a FireTV using the harmony as a controller. The really cool part is that the downstream GUI or Alexa based input doesn't need to know anything about the fact that the work is being done by the Harmony node. It doesn't care. It simply sends {"command", "Menu"} to a topic "MyHouse/LivingRoom/FireTV" via MQTT.

So, my ask, is:

  1. to create a variant of the H Command node : H Device.
  2. H Device lets the user select Hub and Device
  3. H Device lists all commands associated with said device (in a "copy to clipboard" friendly way)
  4. H Device responds to a json payload that sets the Command and sends it to the device selected in "TypeError: Cannot read property 'startActivity' of undefined" #2
  5. If json includes a deviceId it ignores the preselected device and uses the json provided deviceId instead.

image

image

@Aietes
Copy link
Owner

Aietes commented Aug 24, 2018

Thank you for the detailed description @skavan ! Makes sense. Here is what I suggest: A new node is not really needed. What you describe can be achieved with the H command node. I would change the node so that it parses the input it receives. If the input is an object with the properties "command" and "deviceId", it checks if the deviceId of the input object matches the deviceId configured in the command node. If yes, the node sends the command that was handed in. As an easy way to acquire a list of commands, I'll add a button in the H command node that triggers a node-RED notification (pop-up) with the available commands for the selected device.

I believe the above covers your use case. For each device or activity, you would create one H command node, select a Hub and Device/Activity once, get the commands for your reference, and then hand in the commands as needed.

Since I'm traveling for a while, I'll probably do this in roughly 2 weeks from now.

@Aietes Aietes reopened this Aug 24, 2018
@Aietes Aietes self-assigned this Aug 24, 2018
@skavan
Copy link

skavan commented Aug 24, 2018

no worries on timeline...I'm glad it made sense.
the reason I suggested H device, is right now in, H command one selects/creates Hub and then Activity. There isn't a presentation of devices!
In this new mode, one would select Hub and then Device.
I suppose you could add a Device selector under the Activity Combo -- or present both Activities and Devices under the current drop-down with a separator -- I think this is what you are suggesting -- and I'm sure it would be fine - in fact, it would even extend your node for normal users as it would allow them to essentially control devices rather than bundles of devices attached to an activity!

node gui:

  1. Select hub as today.
  2. Select device (new)
  3. Button to display available commands for device in "TypeError: Cannot read property 'startActivity' of undefined" #2 (extension of current gui).

node code:

 if (Json Payload) or (String that is valid Json) then
     if deviceId is a value then
          send json command to json deviceId
     else
          send json command to node deviceId
     end if
 else
          send node command to node deviceId (normal function)
 end if

@skavan
Copy link

skavan commented Sep 15, 2018

Hiya, any update?

@Aietes
Copy link
Owner

Aietes commented Sep 16, 2018

I'll get to it soon :)

@onebyside
Copy link

Looking forward to it

@bakman2
Copy link

bakman2 commented Oct 30, 2022

I dont know if this node is still under development but the node-red-harmony-websocket node has a sequence and command node available, (on the surface) it looks simple to include it in this node. The command node can be controlled via payload as well.

SCR-20221030-9yn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants