Basenode woes
28 March, 2013 - 18:36
I have had problems in the past with my basenode but all has been running well until this recent cold snap came in. First I had an issue with boiler control lua script. It was crashing and taking down plugboard, obviously no longer controlling the heating. As all the rommnodes no longer reported after the crash I suspected the base node.
Before replacing I hooked up to a serial port and got the following at start of comms....
[RF12nocfg.1] A i1 g212 @ 868 MHz
I transferred the AtMega to a spare node and then I got...
[RF12nocfg.1] A i1 g212 @ 868 MHz
Current basenode configuration:
A i1 g212 @ 868 MHz
So I suspect the RFM12B has failed in some way and isn't being configured.
30 March, 2013 - 12:14
#2
Most unusual
I'd first wondered if the issue that you are seeing was down to something temperature related. However, the outside monitor seems quite happy with the unseasonally cold readings.
The baseNode iteslf looks good - in that the outside reports are steady. I'm sure that you'll have already checked the antenna length/position on the Living Room roomNode.
One thing that might be worth considering is reviewing the roomNode code to see if the AVR watchdog monitor is in use. I've not been there yet, but if there is an intermittent hangup on the micro, this would perhaps bring it back to life in a very short space of time.
Keep us posted on any progress.
Derek.
30 March, 2013 - 18:17
#4
Sucking eggs
Try doubling the antenna length on that roomNode. I've also noticed that, despite being battery powered, the roomNodes do like to be away from mains powered kit. Definately away from TVs and PCs.
RF. Gotta love it.
Derek.
27 June, 2013 - 11:31
#7
see next post
see next post
26 June, 2013 - 13:41
#8
Probably a simple solution
Hi
I have started getting plugboard errors like this:
lua: /usr/share/lua/5.1/xap/init.lua:395: /usr/share/lua/5.1/xap/jeenode.lua:51: invalid value (nil) at index 2 in table for 'concat'
xAP Message being processed.
xap-header
{
uid=FF00D500
source=dbzoo.livebox.Serial
hop=1
class=Serial.Comms
v=12
}
serial.received
{
data=OK 34 215 1OK 34 21OK 2 215 0 200 0
port=/dev/ttyUSB0
}
stack traceback:
[C]: in function 'error'
/usr/share/lua/5.1/xap/init.lua:395: in function 'dispatch'
/usr/share/lua/5.1/xap/init.lua:97: in function 'fun'
/usr/share/lua/5.1/pl/List.lua:444: in function 'foreach'
/usr/share/lua/5.1/xap/init.lua:96: in function 'callback'
/usr/share/lua/5.1/xap/init.lua:203: in function 'dispatch'
/usr/share/lua/5.1/xap/init.lua:117: in function 'process'
/etc_ro_fs/plugboard/plugboard.lua:77: in main chunk
[C]: ?
Loading /etc/plugboard/JMaliasApplet.lua [ Alias with Heating Interpreter ]
Loading /etc/plugboard/JMjeenodeApplet.lua [ JeeNode ]
Loading /etc/plugboard/JMxapCacheWebserverApplet.lua[ xAP Caching web servlet ]
Running...
This locks up the plugboard and requires a reboot.
I have a roomnode and a roomnodetwin attached. It looks like a data collision but I don't know how to sort it.
thanks
John
26 June, 2013 - 16:39
#9
Looks like your getting
Looks like your getting combined jeenode signals. Strange.
What versions are you using. There have been quite a few changes recently although they work ok for me.
That said, I haven't used the recent HAHcentral node yet!
27 June, 2013 - 11:29
#10
GarryI've upgraded to the 309
Garry
I've upgraded to the 309 betas and now back to 309 all giving the same errors.
I have also flashed the new HAHcentral to no effect.
John
26 June, 2013 - 21:14
#11
How odd. This just started
How odd. This just started happening? No obvious changes to initiate it?
what do you get if you monitor the base node output (via putty or arduino serial monitor, etc)
Is this a node issue or xap-serial?
Garry
edit: just seen this old post. Is this the same issue?
http://www.homeautomationhub.com/content/hahcentraljeenodeapplet-issues
26 June, 2013 - 23:03
#12
Well its not happy as this
Well its not happy as this data string is clearly broken as the data repeats three times - see the OK marker ?
data=OK 34 215 1OK 34 21OK 2 215 0 200 0
The data is different which would imply you might have either
Two nodes with an ID of 2 there is some data overrun happening? Perhaps xap-serial gets two data feeds really fast and drops the \n and combines them into one. I'll look if this could happen.
Brett
27 June, 2013 - 11:28
#13
sorted
Thanks Garry for the link.
Kevin seems to have got his setup sorted, but begs the question why is no-one else having issues?
I had been experimenting with current cost and had left it enabled on the GUI. When I disabled it all came good.
No more corrupt data like this:
data=OK 34 215 1OK 34 21OK 2 215 0 200 0
data=OK 4 1 0 246 168? 33 70 255 8 186 45 66 15 214 51 45 190 45
data=? 139 1476 227 31 117 217 23 233 215 61OK 4 ? 3 196 124 128 138 153 237 192 169 238 155 214 119 244 79 24 ? 59 60 121 246 6
data=OK 4 1 0 23OK 5 217 1 0 162 48 50 38 146 12
data=OK 5 218 1 0 161 ? 141 161 149 151 196 14 37 254 146 94 ? 185 25 2 18 23 43 77 183 177 68 120 6OK 5 217 1 0 16O ? 182 0 130229
data=OK 4 ? 10 114 241 150 145 246 234 116 0 187 255 167 252 251 51 77 93 174 102 40 158
Anyway same question, has no-one else encountered this?
John
27 June, 2013 - 23:36
#14
You had TWO processes bothing
You had TWO processes bothing trying to access the same serial port /dev/ttyUSB0
Those being xap-currentcost and xap-serial. Strange that the system exhibited this corruption as a symptom I would have thought the second request to open the port would have been flat out denied as the port was already open. Having said that I've seen this being allowed before.
It would certainly explain why nobody has run into this as its a configuration error not a software one. Glad you figured it out.
Brett
28 June, 2013 - 11:01
#15
Multiple processes opening the same serial port
I was looking at xap-serial code and I could see how this could happen as each line is processed and sent as a xAP packet.
It would have to mean that the corrupt string you are pointing at would have had to be emitted from the baseNode itself, which I also find stange as it too can't do this. Which only leads me back to the conclusion that two process esopen the same port and both where consuming data.
That is not to say there isn't a bug, anything is possible, I can't see how it can be happening.
UPDATE: I tested this and I was able to open the same serial port from multiple processes. I've made code changes so that a serial port is opened exclusively to a single process.
With this code in place for John's misconfiguration xap-currentcost would have grab it first, as it starts before plugboard, and xap-serial would deny plugboards request instead push an xAP serial.error packet to say it can't open the port something already has it open, and all your nodes would have stopped working. From there hopefully it would have been a little easier to diagnose this configuration issue.
Brett
29 June, 2013 - 17:39
#16
Brett to the rescue again
Thanks Brett. Silly oversight by me. Sometimes you can't see the wood for the trees!
I fitted a new RFM12 to the basenode. Now I keep losing one of the nodes
Very strange...