New MQTT Gateway crashes
17 March, 2015 - 08:28
Hi Brett,
I just noticed the new gateway is crashing my plugboard if it can't connect to the configured broker.
I'm going to try to fix in my rusty Lua but wanted to highlight issue.
23 March, 2015 - 22:46
#3
The gateway should be
The gateway should be transparent it just slurps xap packets and forwards them "as is" into the MQTT broker.
Can you give me an example of an xap packet that crashed it and the resultant stack trace.
Brett
24 March, 2015 - 10:39
#5
I take it you have munged the
I take it you have munged the xap text when you pasted into this forum?
Because like that it would be invalid.
[[xap-hbeat { v=12 hop=1 uid=FF00D820 class=xap-hbeat.alive source=dbzoo.hal.nodered:xap interval=60 }]]
Having said that I guess there is a parser bug in that its crashes out trying to handle it, I'll look into that.
1. [[ and ]] at the start/end? I think you are confusing those with a lua string block delimiter
We do this in lua.
xap = [[
xap-hbeat
{
...
]]
The [[ and ]] mean take literally everything between those markers, they are not part of the xap message. That also include the \n terminator for each line.
2. Each line must be terminated with \n
In javascript you would need to put those in when building the message.
xap = "xap-hbeat" + chr(10) + "{" + chr(10) etc....
The message should look like this including the \n so each is on its own line.
xap-hbeat
{
v=12
hop=1
uid=FF00D820
class=xap-hbeat.alive
source=dbzoo.hal.nodered
interval=60
}
3. The source= is incorrect and should not have :xap on it for a heartbeat as its invalid.
24 March, 2015 - 11:00
#6
Javascript multiblock string
In Javascript you might find it easier to build the xAP message like this:
var xap= [ "xap-hbeat", "{", "v=12",
"hop=1",
"key=value etc..",
"}"
].join("\n");
24 March, 2015 - 21:23
#9
MQTT broker server restarts
MQTT broker server restarts and the mqtt/xap gw crashing I have fixed for that. You don't have the latest source. Livebox build 317 does not have this version its coming in 318 as a patch, grab it manually.
https://github.com/dbzoo/hah/blob/master/userapps/hah/xap-plugboard/samp...
This also has a fix in it so that it won't process bad xAP packets and crash, which you did earlier.
Brett
1 April, 2015 - 02:10
#12
You should most definately be
You should most definately be able to see the Node-Red endpoint in the xFxViewer. If you can't then your message may not be well formed. The viewer should tell you why its rejecting it.
I noticed that you are using ID=A2 in your message I find it easier to just use ID=* and do away with any direct UID endpoint addressing as this can mess things up if you don't get it absolutely right.
Also as a source you don't send from an ENDPOINT like this.
"source=dbzoo.hal.nodered:xap", "uid=FF00D807",
You would use this:
"source=dbzoo.hal.nodered", "uid=FF00D800",
Even if your NODE-RED has a dbzoo.hal.nodered:xap endpoint you never transmit as it.
As you say your addressing is somewhat off which is probably causing you issues.
What you want is something like this on your NODE-RED:
msg.payload = [
"xap-header",
"{",
"v=12",
"hop=1",
"class=xAPBSC.cmd",
"target=dbzoo.hal.Controller:rf.3",
"source=dbzoo.hal.nodered", // Use the top level address not an endpoint.
"uid=FF00D800", // 00 for the unit a whole, 07 would be an endpoint of the unit.
"}",
"output.state.1",
"{",
"state=toggle",
"ID=*", // You can use * here its easier and works the same.
"}"
].join("\n");
return msg;
Brett
3 April, 2015 - 00:20
#14
NODE-RED
Hi Bodge .. sounds good.. what hardware are you running NODE-RED on and have you added it to a HAH setup ?
Have you a xAP node written or perhaps intended for NODE-RED or are you going via the MQTT route ?
I'm using NODE-RED (ThingBox) and have been originating heartbeats and my xAP messages directly, and receiving /parsing xAP in a very crude fashion, but it is working OK . Playing with MQTT too , but not yet the HAH one but I'll get there.
Re The xAP errors in xFX Viewer I would really encourage people not to drift from the specification. If Viewer shows an error then its worth fixing, as other apps might balk e.g. iServer - I can point you in the right direction xAP spec wise if you post a problem message. Sounds like you may have varying source addresses and fixed UID or vv.
The ID=* is a wildcard workaround to including a specific subaddress, however it does often make life much easier for the targeted device if the ID= is defined (when the target is not wildcarded) as it avoids having to search all subaddresses for matches. For example in my C-Bus gateway with over 2200 endpoints it makes a huge time/cpu difference as the ID can directly identify the endpoint. If your target address is wildcarded then of course your ID= must be too and that's a real workout for the device as multiple endpoint matches can happen.
3 April, 2015 - 14:33
#16
NODE-RED xAP node
Martyns xAP function didn't work for me either but I didn't spend much time working out why. ISTR it was a call into some nodeJS function and I think I had it installed wrong. Regardless a dedicated xAP BSC node would be better but probably beyond me too. I'm doing useful xAP things with just the TCP node and iServer so I'm making progress.
I've looked a bit more at the xAP MQTT bits that Brett posted on GitHub so I'm more familiar with how you're working currently.
The bus thing sounds novel and useful.
Keep us posted.... K
Thanks Bodge. I did throw it together in a hurry so I'm not suprised.
There is no error handling or retry logic if the MQTT server is either not present or disappears and comes back. Yep thats something that needs to be added.
Brett
UPDATE: fixed