OutputNode info

8 October, 2011 - 21:51

#1

brett

Offline

Providence, United States

Joined: 9 Jan 2010

Jeenode enpoints

Gary jeenode endpoints are BSC compliant - I can give you an example but this is EXACTLY the same schema as the RF and RELAYS so I'm pretty you've got this nailed already.

You never interact with xap-serial directly this is just an intermediary that is realying the traffic. As I previous said the enpoints are BSC nodes.

Even without the hardware you can setup the jeenodeApplet.lua and create some endpoints to get a better understand.

So it we setup this NODE configuration
local nodes = {
  [2]=OutputNode{base="dbzoo.livebox.jeenode:attic"},endpoints={p1=1,p2=1,p3=1,p4=1}}
}

We could send a BSC message to enable endpoint P1 like this.

xap-header
{
v=12
hop=1
uid=FF000F00
class=xAPBSC.cmd
source=dbzoo.livebox.demo
target=dbzoo.livebox.jeenode:attic.p1
}
output.state.1
{
id=*
state=on
}

Now we are also able to RENAME the endpoints
local nodes = {
  [2]=OutputNode{base="dbzoo.livebox.jeenode:study"},endpoints={p1="tv",p2=1,p3=1,p4=1}}
}

We could send a BSC message to enable jeenode PORT1 like this.

xap-header
{
v=12
hop=1
uid=FF000F00
class=xAPBSC.cmd
source=dbzoo.livebox.demo
target=dbzoo.livebox.jeenode:study.tv
}
output.state.1
{
id=*
state=on
}

1 December, 2012 - 20:53

#2

ian7

Offline

Joined: 1 Oct 2012

Output Node and xap-serial crashes

Brett,

I wonder if you have heard of the xap-serial process crashing when sending xap frames for a output node. We are able to send an on, state and a off state and see the port turn on a led and turn it off again, using p1 in this example. After that attempting to send another frame to our output node seems to crash the xap-serial process and it disappears from the ps list. sometimes we see the plugboard process crash also. We thought it may have something to do with the usb hub as we also have a current cost usb cable attached also, but taking out the current cost and running the hah central direct into the livebox usb port gives us the same symptons. Does anyone have any ideas.

I am also not sure if we are running the correct output node sketch as the sketch seem to be exepecting 49,49 to turn on the port, but the plugboard sends 1,49 to the outputnode so had to take away the statement that subtracted '0' from the first digit. to get it working. I wonder if you could shed any light on this problem also.

Regards ian

2 December, 2012 - 04:47

#3

brett

Offline

Providence, United States

Joined: 9 Jan 2010

Ian, never heard of this

Ian, never heard of this problem. If you run xap-serial in debug mode from the command line and/or check /var/log to see if there is any messages being logged for a crash this will help me isoate things.

Something like:

# xap-serial -d 6 -i br0

You'll need to leave a session connection to your livebox so you can see this output debug.

Brett

2 December, 2012 - 16:55

#4

ian7

Offline

Joined: 1 Oct 2012

Result of running xap-serial in debug mode

Hi Brett,

Below is what I get from xap-serial when in debug. Problem is I think its going to be difficult to find as it is obvious this works ok for you and other. Tried using python and the joggler to send the xap command, same result from both.

Just editing an update to this post, I have discovered that the problem was due to my own hacking, I am modifying the roomnodes so they will control the conrad TRV valves, the central node got a little modification so I could send data to the roomnodes to control the valve, the modification was working ok until we introduced the output node and there was not enough intelligence in the central node modification to distinguise between a room node and a output node. Will try and work out later why this was having such a dramatic effect, but solved it by hacking my own hack some more.

Regards Ian

[inf][serial.c:291:sendSerialMsg] send to /dev/ttyUSB1 '1,48,6 s'

Segmentation fault

#

4 December, 2012 - 10:48

#5

brett

Offline

Providence, United States

Joined: 9 Jan 2010

Well I guess if you stare at

Well I guess if you stare at the code long enough you'll find A bug - unfortunately its not related to this segv, just a typo that affects the debug out.

Really curious how you manged to segv the xap-serial process thou, even if you where throwing bad data its way, thats no reason for it to die.

If you can still repo that issue you can up the debug level to 7 and try again, perhaps its breaking in the xap library because I can't immediately see how this could be happening in xap-serial.

Brett

6 December, 2012 - 11:43

#6

ian7

Offline

Joined: 1 Oct 2012

Hi Brett, The hack I have

Hi Brett,

The hack I have introduced is a means of sending a control byte to a roomnode. I am hacking the jeenode sketches in the room node and central node. What I have done with the central node is set up some variables to store a byte of data for each roomnode. I have introduced another command for the central node that is serial data that contains roomnode id and the control byte. The control byte contains info on room temperature setpoint and manual valve position if the additional PID routine is disabled in the roomnode, this controls the Conrad valve we are using on the central heating radiators. The Conrad valve sleeps for about 2minuites and wakes up to recieve data from the roomnode, the roomnode must wake up at the exact time to send this data, and because the room node has to sleep, I get the central node to send the stored control byte just after the room node sends its normal status transmission over RF. When the control byte is recieved by the central node, it sends the control byte up the serial so that I can see what the status for the valve is. For the Outout node this status was bogus, but I think it was this that was crashing the xap-serial. Does not explain though why it did not crash for the roomnodes also.

Obviously not really the best way to do things, I would like to add endpoints using lua to keep the system within the live box and possibly include the valve status in the normal roomnode status transmissions, lua not very proficient with it at the moment and most of my xap play has been done with a seperate linux box using python.

I will try the debug level 7, when I get time and let you know my progress.

I am not familiar on lua and just an amateur on programming so for the moment I am just using xap serial commands to change the valve status, hopefully I might learn how to introduce endpoints to the serial commands in the future using lua to keep the system as one unit, rather than playing with python on another linux PC as what I am doing at the moment.

Regards Ian

13 March, 2013 - 21:04

#7

garrydwilms

Offline

United Kingdom

Joined: 31 Mar 2011

Me too

Ian,

Did you ever get to the bottom of this? I too am creating a segv fault in xap.serial when trying to send data to a slightly modified output node. The data I'm trying to send looks ok to me?

I have posted info from debug level 7 showing the data I was trying send.

any advice gratefully received!

thanks

garry

[dbg][rx.c:23:readXapData] Rx xAP packet

xap-header

{

uid=FFD80000

source=dbzoo.livebox.Plugboard

hop=1

class=Serial.Comms

target=dbzoo.livebox.serial

v=12

}

serial.send

{

data=1,48,4 s

port=/dev/ttyUSB0

}

[dbg][parse.c:33:xapGetValueF] section=Serial.Close key=

[dbg][filter.c:136:xapCompareFilters] match=0

[dbg][parse.c:33:xapGetValueF] section=Serial.Send key=data

[dbg][parse.c:42:xapGetValueF] found value=1,48,4 s

[dbg][parse.c:33:xapGetValueF] section=Serial.Send key=port

[dbg][parse.c:42:xapGetValueF] found value=/dev/ttyUSB0

[dbg][parse.c:33:xapGetValueF] section=xap-header key=class

[dbg][parse.c:42:xapGetValueF] found value=Serial.Comms

[dbg][filter.c:53:xapFilterAddrSubaddress] filterAddr=Serial.Comms addr=Serial.Comms

[dbg][parse.c:33:xapGetValueF] section=xap-header key=target

[dbg][parse.c:42:xapGetValueF] found value=dbzoo.livebox.serial

[dbg][filter.c:53:xapFilterAddrSubaddress] filterAddr=dbzoo.livebox.serial addr=dbzoo.livebox.Serial

[dbg][filter.c:136:xapCompareFilters] match=1

[dbg][parse.c:33:xapGetValueF] section=serial.send key=port

[dbg][parse.c:42:xapGetValueF] found value=/dev/ttyUSB0

[dbg][parse.c:33:xapGetValueF] section=serial.send key=data

[dbg][parse.c:42:xapGetValueF] found value=1,48,4 s

[inf][serial.c:291:sendSerialMsg] send to /dev/ttyUSB0 '1,48,4 s'

Segmentation fault

#

EDIT: it appears to be the 48 that's the issue? Sending 1,0,4 s is ok as is 1,49,4 s

i can get round this by modifying the outputnode to:

self:sender(port..","..tonumber( utils.choose(e.state=="off",0,1))) from:

self:sender(port..","..string.byte( utils.choose(e.state=="off",0,1)))

so now 1,0 gets sent as the state rather than 48,49 and then modify the outputnode sketch to remove the ascii conversion. However, there does appear to be a bug lurking in xap-serial somewhere?!

Cheers

Garry

14 March, 2013 - 00:56

#8

brett

Offline

Providence, United States

Joined: 9 Jan 2010

The bug is here char

The bug is here

char *unescaped = (char *)malloc(strlen(data));   <--- bug
    size_t len = unescape(unescaped, data);
    sendSerialMsg(p, unescaped, len);
    free(unescaped);

The malloc() is 1 byte too small as its strlen() and it should be strlen()+1 to include the NULL terminator. Which means the unescape call is writing 1 byte over the top of something else producing random crashes.

Let me fix this.

UPDATE: I've posted 307.3 as a beta for you to try if this resolves your problem I'll post this as a 308 as everybody should have this fix.

Brett

15 March, 2013 - 21:24

#9

garrydwilms

Offline

United Kingdom

Joined: 31 Mar 2011

Sorted

Brett, won't pretend to understand what the issue was but you sorted it.

cheers

Garry

Site Navigator

Shop

Who's online