I’ve been looking on YouTube (more obscure results, harder to get what I’m looking for) or other places before, I asked when I hit a dead end. For the node part (I know you said you haven’t done it), you mean the XMPP node connected to the switch along with event_state (such as Light) or such? And if MQTT is an input, it’ll be connected to the switch part too? And OpenFire is the one that sends the XMPP message within the node I guess (but not put the server on Pi?).
So, anyone else got other ideas?
XMPP IN linked to a function node so you can parse the message and do something with it - eg:
var parts = msg.payload.split(" ");
msg.onoff = "";
switch (parts[0].toLowerCase()) {
case "switch":
msg.action = "turn";
break;
case "turn":
msg.action = "turn";
break;
case "activate":
msg.action = "turn";
msg.onoff = "on";
break;
case "deactivate":
msg.action = "turn";
msg.onoff = "off";
break;
default:
return null;
}
if (msg.onoff == "") {
msg.onoff = parts[1].toLowerCase();
}
msg.device = parts[2].toLowerCase();
return msg;
From that point you will know if you want to turn on or off a device based on the content of the XMPP message, then you can use a switch node to change where the flow goes based on whether msg.onoff is on or off.
So if the message was something like turn on GPIO2 then msg.action is turn, msg.onoff is on and the device msg.device is gpio2
That’s the basics of it.
As far as I know the only way to send that back to Home Assistant though would be on MQTT so you would need to publish something back like:
topic: picontrol/state/gpio2
payload: on
And have the MQTT switch in Home Assistant with something like:
switch:
- platform: mqtt
name: GPIO2 Control
state_topic: picontrol/state/gpio2
command_topic: picontrol/control/gpio2
You would then have an MQTT IN ( topic: picontrol/control/+ ) node in the same flow and to get the device information you would do something like this in a function node:
var parts = msg.topic.split("/");
msg.device = parts[parts.length-1].toLowerCase();
msg.onoff = ((msg.payload.toLowerCase() == "on" or msg.payload == 1) ? "on" : "off");
return msg;
This can now be fed in to exactly the same switch node input as the XMPP messages.
Once you have turned on or off the GPIO then you would post the message back to Home Assistant via MQTT - so something like this in a function node:
msg.topic = "picontrol/state/" + msg.device;
msg.payload = msg.onoff;
return msg;
Feed that directly in to the MQTT OUT node, leaving all the settings to set by msg
OK thanks for the further help, though I wonder where do you get to know more about building this. Is the node built like this (for an on/off)? Where did I got wrong here?
Does this only use 1 switch (and is only about msg.onoff)? And does the switch lead into call service node which I use the existing GPIO entity? And does picontrol/control/+ is written as such where + means generally?
And where is the
topic: picontrol/state/gpio2
payload: on
part located? On the mqtt section in configuration.yaml (the configuration wasn’t valid that way for mine)?
I have questions…
-
Why are using Home Assistant to do anything with Pi’s GPIO pins? There are GPIO nodes in Node Red, if you are doing it with Home Assistant, then I’m not sure what the point of the XMPP is?
-
picontrol/control/+the + means some other word can appear here. We use this so all the GPIO switches are using the same topic.
Ignore this bit:
topic: picontrol/state/gpio2
payload: on
Because I gave you the actual code you need to use at the bottom of my post:
msg.topic = "picontrol/state/" + msg.device;
msg.payload = msg.onoff;
return msg;
And I gave you the code you need in configuration.yaml:
switch:
- platform: mqtt
name: GPIO2 Control
state_topic: picontrol/state/gpio2
command_topic: picontrol/control/gpio2
So the part of using Home Assistant to do with GPIO pins is just wrong then, how about this node configuration then? (the GPIO node is said to only accept 0 or 1 input)
What’s the 2nd output of the xmpp node? Also are the MQTT nodes connected to the xmpp one or each other (input and output)?
Right so in that case swap the switch node probably wants to acting on msg.device then instead, so that the message is routed to the right GPIO node. The code in the XMPP and MQTT functions would be changed slightly to something like this:
XMPP Node:
var parts = msg.payload.split(" ");
msg.onoff = "";
switch (parts[0].toLowerCase()) {
case "switch":
break;
case "turn":
break;
case "activate":
msg.onoff = 1;
msg.device = parts[1].toLowerCase();
break;
case "deactivate":
msg.onoff = 0;
msg.device = parts[1].toLowerCase();
break;
default:
return null;
}
if (msg.onoff == "") {
msg.onoff = parts[1].toLowerCase();
msg.onoff = (msg.onoff == "on" ? 1 : 0);
msg.device = parts[2].toLowerCase();
}
return msg;
and the MQTT function:
var parts = msg.topic.split("/");
msg.device = parts[parts.length-1].toLowerCase();
msg.onoff = (msg.payload.toLowerCase() == "on" ? 1 : 0);
return msg;
Both the XMPP function and the MQTT function would then link to the switch node, but also to another function node to prepare the MQTT out message:
var topic = "picontrol/state/" + msg.device;
var payload = (msg.onoff ? "on" : "off");
msg = {};
msg.topic = topic;
msg.payload = payload;
return msg;
Feed that in to the MQTT out node.
Remember to figure out what is going on and that things are working as they should, drop the debug node in there, set it to complete msg object, instead of the default of just showing msg.payload. And wire any node you need to know what is happening at that part of the flow - to the debug node.
So far the node is structured like this, what should be changed again? (and what’s the 2nd link on XMPP in):
For this flow, what should be filled on the “Buddy” section of the XMPP node? And what’s filled on the Buddy will be added as contact or such in applications like Spark IM to chat with?
So many things wrong here…
The MQTT In Function wants it’s output linked to the inputs of the Switch AND the MQTT Out Function.
The XMPP Function wants it’s output linked to the Switch Node AND the MQTT Out function.
Right now you have the XMPP Out Function leading in to the Output of the MQTT In Function which is impossible, and the IN of the Switch and the IN of the MQTT Out function linked together, which again is impossible.
Next you should have a GPIO node linked to EACH output of the Switch Node, since you said you can’t use msg to tell the GPIO node which GPIO to control, you have to enter it in to the node itself, so you need one for each switch output.
You don’t yet have the MQTT nodes connected to an actual MQTT server, or if you do then it isn’t working. You don’t yet have the XMPP node connected to an actual server either.
The GPIO out node is “not available” probably because Home Assistant is connected to the GPIO ports - judging by a previous post you showed.
I have never used XMPP in Node Red, I have no idea how to set up the node, or what information you get from it. You would be best advised to read the documentation on it.
The Buddy field is the id of the buddy or room you want to receive messages from.
Incoming messages will appear as msg.payload on the first output, while msg.topic will contain who it is from.
The second output will show the presence and status of a user in msg.payload. Again msg.topic will hold the user.
I guess you’re reading my picture wrong (I should stretch the nodes to explain it better), I did link the MQTT In Function output to the inputs of the Switch and the MQTT Out Function. Also XMPP Function’s output on the Switch Node and the MQTT Out function, for the clearer pic:
Next you should have a GPIO node linked to EACH output of the Switch Node, since you said you can’t use msg to tell the GPIO node which GPIO to control, you have to enter it in to the node itself, so you need one for each switch output.
Enter it in to the (gpio?) node itself? Sorry, so far I haven’t found the place to insert it, which part of the node?
You don’t yet have the MQTT nodes connected to an actual MQTT server, or if you do then it isn’t working. You don’t yet have the XMPP node connected to an actual server either.
OK, now my MQTT can be connected, it’s about my set static IP finally working again.
For XMPP, yeah it hasn’t, which was where I suspected it due to not filling Buddy section yet. Currently the XMPP node Properties are filled with OpenFire’s “Server Host Name (FQDN)” for Server, username@FQDN for JID, and a set nickname and password.
The GPIO out node is “not available” probably because Home Assistant is connected to the GPIO ports - judging by a previous post you showed.
Yeah, and of course those GPIO ports are used for another protocol like MQTT to compare. Any solutions for that or I should use another unused GPIO for the XMPP one here?
While waiting for the next answer there ^, anyone else have another idea of implementing XMPP on GPIO?
It very clearly tells you that the pins in use are 35 (GPIO19), 36 (GPIO16), 37 (GPIO26) , 38 (GPIO20) and 40 (GPIO21). And it very clearly has 36 in the box above “Digital Output”. This is what I was referring to - you are hardcoding the pin in the node, thus you can’t use the same node to control multiple outputs. You need a node for each output you want to control.
No, there is no solution, I’m not sure why you are “comparing” it with XMPP, when I have already provided you the complete flow which will take both XMPP AND MQTT messages in and control the output, what else were you wanting to do with MQTT? You should only have one “app” controlling the pins at any one time.
Sorry if this is probably unneeded question, but then should I use another pin for the XMPP device? Like if already hardcoded pin 19, 16, 26, 20, and 21, I should use GPIO5 for example?
I’ve already used this and this (the one I talked to you before) one as the programs for the MQTT protocol smart home before, so now I’m making the XMPP one (as per my assignment) to compare the protocol’s performance to said MQTT one (the project is about comparing HTTP, MQTT, XMPP, and WebSocket’s performances as smart home protocols).
If you are comparing the performance, then usually you use identical setups, so you would use MQTT for a week, and then stop using MQTT and use XMPP instead. Using different pins could introduce a bias in the results, it’s unlikely - but for a true comparison, you would keep the set up as close to the “control” setup as possible.
Using different pins, or suddenly using WiFi instead of ethernet, for example - would be like a phone reviewer testing a set a phones by having them play a video on a loop continuously until the battery dies - but having each phone playing a completely different video (which would have an impact, especially on phones with LED displays).
If you absolutely have to test the protocols at the same time, then yes you will need to use different pins for each, there is no way around that. But be aware that if you are testing all the protocols at the same time, it is not a fair comparison. Each protocol has some overhead, whether that is on the wire, or in the processing. The only fair way to test all the protocols at once, is to have a Raspberry Pi for EACH protocol that you are testing, running ONLY the software needed for the protocol you are testing.
I guess I’m not testing the protocols at the same time, I probably plan to capture each of the protocols’ performance using a packet analyzer app, for 1 protocol at the time. And as expected, probably using different pins can get different result, and true I want to keep the set up as close to the control setup as possible. So I guess I’m following the “you would use MQTT for a week, and then stop using MQTT and use XMPP instead”, though sorry I don’t know how to do that? (in NodeRED? Or stopping MQTT as in clicking “Stop” on HA’s MQTT Integration)
Other than that, what changes should I do now for the node that I’ve made in NodeRED?
It really depends on how you process the protocols. So if for example you have a different way of doing MQTT (and I would hope you aren’t using Home Assistant to actually act on the MQTT messages, for example - because then you are not accounting for the additional processing that Home Assistant can introduce in to the processing flow).
If it was me, I would probably do all the processing in Node Red for each protocol, because a) there are nodes available for pretty much all the protocols. And b) it’s easy to measure the processing delay that Node Red adds to “control” and then account for that delay in ALL the protocols. You would then simply create a flow for each protocol, and disable ALL of them except for the one that you intend to test.
I don’t know if I’d got time for re-making all the processing in NodeRED for each protocol, I probably will comment out the Raspberry Pi GPIOs in the configuration.yaml if I’d want to test a protocol using NodeRED (like XMPP here). I don’t know if I’m wrong again but the other protocols are all using Home Assistant so I guess all will have HA’s additional processing.
So again, what changes should I do now for the node that I’ve made currently?
So for now, anyone got other ideas to accomplish this?
What exactly are you trying to accomplish?
- Using RPi GPIOs for Home Assistant - are you running HA on the Pi? How did you install HA?
- What do you want to connect to the GPIOs? Is it supported as an integration?
- What role is XMPP supposed to play here? A chatbot that can set and fetch states of entities of Home Assistant?
- You want to compare IoT protocols - what are you trying to compare? What are the parameters?
MQTT and XMPP are really different, which a lot of articles and stackoverflow posts talk about, there are even direct comparisons, if your project requires a comparison, you’d most likely want to capture some of the traffic to analyze it, taking a look at the system load when dealing with 1000+ messages and write about stuff like QoS, encryption, etc. - Why are you using Home Assistant in the first place? Not that it’s a bad thing, but if all you want to do is compare protocols, you’d just get a simple library for each protocol, copy an appropriate example and just use simple command line tools to interact with the pins
If you want to use Home Assistant, great, but please take the time and watch a couple of beginner guides, there are great ones on YouTube talking about how Node-RED and Home Assistant work together as well as how MQTT and Home Assistant work in general, this will save you a lot of time in the long run.
The Supervised one.
I’m making a miniature smart home with ON/OFF devices (light, fan), garage, and binary sensor (PIR sensor, flame sensor).
Of course it’s different, didn’t say that they’re the same or such. To be specific, I’m comparing the IoT protocol’s performance regarding how they handles my miniature smart home, so obviously I have to create the smart home programs for each IoT protocols.
Trying to be consistent, I’ve used Home Assistant for both the HTTP and MQTT protocol for the smart home (the ones that I compare are HTTP, MQTT, XMPP, and WebSocket, and I’ve completed all except XMPP).