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?
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?
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.
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).
