I’m not sure I should just drop a JSON blob here, and I’m not sure it’d be entirely helpful to you anyway as its specific to my setup so you’d have to heavily modify it. Also I can’t guarantee its still right because I use Google Home now. But I can give you an idea of what I did.
I added a POST endpoint per room (I based all commands on “turn on [room] [device]”, etc. I had ONE endpoint at first, but this worked better for some reason, and I do an Alexa skill per room.
Because I did an endpoint per room, I modified the message coming in to add msg.payload.request.intent.slots.room = { “value”: “master bedroom” }; for instance, since Alexa wasn’t responsible for sending me that anymore.
I checked message type and only process “IntentRequest”. There is also “SessionEndedRequest” and “LaunchRequest”, but for basic control you don’t have to deal with these.
I then parse the intent type Alexa sent. For me, these are intent types I created in the skill, like “OnOffIntent”, “LevelIntent” and “OpenCloseIntent”. Each requires a slightly different message to eventually be sent to my MQTT system, so I treat each a little differently.
Then the only tricky part: Alexa’s role is done here. so for every output of the switch, I go to a node that builds a response message, and then to an http return node. You can build the message with a template or function node (latter is better IMO). Just do a “return { … };” in it. The message format is documented, but here ya go:
Then for each of those output nodes on the switch you can also link to whatever your internal actions need to be. For me this is building MQTT messages on the slots the Alexa message sent over, but this’ll be specific to your implementation of the skill and your system. My nodes end up building an intermediate message that I then pass to a function I wrote to build an MQTT message from that format:
var room = msg.payload.request.intent.slots.room.value;
var device = msg.payload.request.intent.slots.device.value;
var value = msg.payload.request.intent.slots.onOffState.value;
var newMsg = {};
newMsg.payload = {
room: room,
device: device,
value: value
};
return newMsg;
One thing that I’ll point out: Alexa requires you to use SSL, so you are going to have to figure out how to enable SSL on your node-red installation. Alexa will let you self sign and upload a public key for verification in the skill. Google will not, so I actually use letsencrypt to get a real cert.
You will also need to poke a hole through your router firewall for port 443 and point it at the node-red install.
But if you really want to lock this down correctly, here’s what I did:
Install nginx on the machine.
Leave node-red in default mode, no SSL.
Setup letsencrypt on the box and get an SSL cert onto the nginx install correctly. Good luck, this was a pain in the ass.
Setup nginx to proxy the node-red install, and to allow external IPs to ONLY access the Alexa endpoints you created:
Does the extra processing add much delay in rule execution? Being a non-programmer this looks like a much easier way for rule creation and I like the other integrations available.
I have a few light rules that trigger off manual switches so trying to make sure they trigger as soon as possible to when the other switch is turned on/off.
I played with it for about an hour today and it doesn’t seem to have as much flexibility as the text based rules files (for example it only triggers a new message when a value is changed, whereas in the OH2 rules I can fire off a rule when a value is updated even if it is updated with the same value)
@Peter_De_Mangelaere Thanks for putting together the OH2 node. Is it possible to expand the in bound messaging to include the same types of trigger events as OH rules (received update and received command)? Specifically I use the on update quite a bit where I want to capture a trigger event even if it doesn’t change the actual state of the item.
Just my two cents, I played with Node-RED as a rule processor for OpenHab2. I did this because the JavaScript plugin was not available for OpenHab2 at the time. I dislike XTend(?). I find it very clunky. In the end I implemented all of my rules in standard Node JS modules. I found implementing rules in Node-RED such as “turn off this light in ten minutes unless something else happens or something wants to keep it on for longer” difficult to define in Node-RED. In Node they were still a pain but I felt I had a more granular level of control.
I’m new to OH and OH2, but have some experience using Node-RED. Since the Dashboard capabilities of Node-RED are very poor, I’d like to create a Home-Automation Dashboard using OH2.
The MQTT-Service-Bus way is preferable IMO, since you also can be used by other Devices, e.g. PLC controller. Anyhow, is there an easy tutorial or description, on how to create a beautiful dashboard using OH2? Until now, I only found some very basic tutorials that allows me to paint grey boxes!
An alternative would be using the iOS App OpenHAB for to control the home. Is there any description / tutorial on how to create App compatible Items, Things etc.?
HABPanel is built wholly within the browser using drag and drop and form entries. There are tons of examples, howtos, and third party javascript libraries available on the forum.
I don’t know what tutorials you have found but I can say that any Sitemap, and any OH configuration in general, starts with Items. You need to define Items for each of the things you want to represent in your sitemap. Presumably, these will all be MQTT Items.
It took a little longer than expected … I updated node-red-contrib-openhab2 based on rgerrans’ request.
Please check the documentation.for the changes.