Until iHost has a native MQTT broker I’m using it as a zigbee bridge to a rPi.
My iHost receives messages from my zigbee sensors & publishes to MQTT on the rPi.
I have node-red on the iHost & the rPi. I use both & the setup works fine.
I need to uniquely identify the zigbee devices & imagined the easiest way to do this would be from their serial numbers. For example, I might have a PIR in every room of my house & I need to know which is which.
An example flow:
My thinking was that a ‘switch’ node in node-red might do this?
I’ve tried a few different ways of doing this, eg
I’m probably just being stupid…
Almost answering my own question…
Yes, I was being stupid!
I guess it was the ‘payloads within payloads’ which was upsetting me?
I needed to test ‘msg.payload.endpoint.serial_number’
Onwards & upwards!
If anyone has other suggestions I’d love to hear them anyway!
with JSON…and node-red-contrib-ewelink-cube
That’s interesting. I felt sure I’d used a flow very like yours when I first tried to get status of zigbee devices. At the time I was using node-red on the iHost.
I went back & checked. Sure enough, because the ewelink-cube nodes deliver strings we need to parse these or convert to objects with the JSON node. Both approaches worked for me.
Because I want to use MQTT which doesn’t seem to be supported (yet) in node-red on the iHost, I set up an Aedes MQTT broker on a rPi on my network. This seemed to work differently which threw me a little so I’ve had a closer look today. The flow below shows what I found:
This is node-red on my iHost but the MQTT broker is on a rPi. Notice that I don’t have a JSON node here.
The interesting bit is in the debug outputs. This is the STRING coming from the ewelink-cube node:
And this is an OBJECT which pops out of MQTT:
I’m not sufficiently expert to know if this is to be expected. I’d assumed with MQTT that whatever goes in one end comes out the other end unchanged. Clearly not.
Apart from adding to my confusion this is quite useful (in this instance, at least) as I don’t need any json nodes in my flows.
Maybe this is an Aedes thing? I don’t know. Perhaps someone else does?
btw the only reason I went for Aedes over Mosquitto is because I was originally trying to use Aedes on the iHost thinking that it was more likely to work. Wrong again
use a JSON node and the filter will work
what results after the filter you can enter in an MQTT node
Indeed it would
My point was that the json node is effectively there anyway with Aedes mqtt broker which I didn’t anticipate.
There is a rather unpleasant English proverb: ‘There is more than one way to skin a cat.’
Thanks for your input It made me think a little!
What is that light green “Big Timer” thingy you have on your screenshot? What node type is it and what do you use it for?
I can answer that. Big timer is a node created by Pete Scargill to do all kinds of timing things.
I personally don’t like it but it might suit you.
it is a TIMER note
I turn on 2 sonoff zigbee relays at sunset and turn them off at 11pm
@iansexton23 @edmasec Thanks. I found the node at node-red-contrib-bigtimer (node) - Node-RED. It sounds interesting for some purposes, but the iHost is pretty useless for time related things as it doesn’t take Daylight Savings Time into account an Node-RED don’t even take the timezone offset into account and just sticks to UTC / GMT. Result: the trigger to play a cast on my Nest hub that I’ve set for 10:55 got actually casted at 12:55. 2 hours to late…
…I have the same problem
but…I adjusted from the offset and UTC settings
In which way did you adjust? Just by putting in an incorrect time or is there an offset setting somewhere?
I stopped using
node-red-contrib-bigtimer some time ago, but I have been able to meet all my scheduling needs with various combinations of:
I can’t say how well these work in the iHost/Docker environment, but they are fine on my laptop and Raspberry Pi’s.