WH1080 integration
14 December, 2013 - 20:08
I've now got the WH1080 weather station added to my Corona app.
I have a node modified for 433Mhz OOK that is monitoring the transmissions fro the WH1080. This is connected via serial to the HAH.
I'm having a bit of an issue with plugboard stopping but here are the screen shots so far.
A write up will follow on here. I will add to wiki if allowed.
| Attachment | Size |
|---|---|
| Screen Shot 2013-12-14 at 12.00.47.png | 367 KB |
| Screen Shot 2013-12-10 at 22.25.01.png | 369.87 KB |
31 December, 2013 - 01:16
#2
Mark, NICE JOB... No
Mark, NICE JOB... No optimization neeed - it works leave it alone !
2 January, 2014 - 22:17
#5
I've seen plugboard die when
I've seen plugboard die when a bad packet comes its way - I ran into that only yesterday when I was hacking around with the BT stuff. I will look into making the xAP parser more robust to bad packets. A bad xAP packet should be discarded and not cause a crash.
My excuse was that I sent it in the XfXviewer. Why are you getting bad packets?
Brett
3 January, 2014 - 04:40
#7
Mark I found some issues with
Mark I found some issues with the __tostring() method for a Frame but for the life of me could not get the xAP parser to crash. Unfortunately I restarted plugboard before I thought about fixing the issue so I've lost the traceback.
If anybody gets a packet that crashes out the xAP parser please let me know what did it and send it my way.
Brett
5 January, 2014 - 05:46
#11
Mark there is more too
Mark there is more too it.
That xAP message does not crash the parser it crashes out the FILTER engine because just sending that xAP packet onto the wire does not cause a problem. No wonder I could not reproduce I was looking in the wrong spot !
I will try with the applet that you posted here and see what filters you are using, perhaps that will get me closer to the issue.
At least I know where to look now. Thx.
Actually from that line number the error is in the ERROR handler - which I know as I just fixed that in 311.2 beta - so the REAL error is being masked. You need to upgrade to the to take the fix I did for this so we can identify the underlying issue. Please upgrade and keep your system running as usual as we should get a different stack trace this time !
init.lua
395: error(err..'\nxAP Message being processed.\n'..tostring(frame))
Brett
5 January, 2014 - 06:09
#12
Never mind I found the bug -
Never mind I found the bug - let me walk you through why this happens.
Loading luaxap/testApplet.lua [ WH1080 decoder ]
Running...
build/bin/lua: /home/brett/lua-development/luaxap/xap/bsc.lua:181: attempt to concatenate field 'text' (a nil value)
stack traceback:
/home/brett/lua-development/luaxap/xap/bsc.lua:181: in function 'infoEventInternal'
/home/brett/lua-development/luaxap/xap/bsc.lua:192: in function 'sendInfoEvent'
/home/brett/lua-development/luaxap/xap/bsc.lua:129: in function 'sendInfo'
/home/brett/lua-development/luaxap/xap/bsc.lua:102: in function 'callback'
luaxap/xap/init.lua:179: in function 'dispatch'
luaxap/xap/init.lua:131: in function 'fun'
build/share/lua/5.1/pl/List.lua:392: in function 'foreach'
luaxap/xap/init.lua:129: in function 'process'
luaxap/plugboard.lua:68: in main chunk
[C]: ?
When you get a BAD xAP message some of your field could be NIL so this happens
bscendpoint:setText(nil)
This in itself is a problem but the bug does not manifest until we report the xAPBSC.event
bscendpoint:sendEvent()
At which point we try to do this with a nil variable
msg = msg .. "text=" .. e.text .. "\n"
Summarizing this is what happens next:
> a=nil
> ="hello"..a
stdin:1: attempt to concatenate global 'a' (a nil value)
stack traceback:
stdin:1: in main chunk
[C]: ?
>
BANG.
The fix is simple alway convert a NIL text to ""
function sendText(target, text, state)
state = state or "on"
text = text or ""
send{target=target, text=text, state=state}
end
Brett
5 January, 2014 - 09:18
#13
The BSC framework will now
The BSC framework will now not let something like this pass and not fall over, arguablly thats is also an applet bug but the framework will help you out a little here now.
endpoint:setText(nil)
However this fix won't completely correct all the issues as you still have a bug in your coding technique.
That is performing arthimetic on the values retreived from the data:match without performing any NIL checks, and those are still fatal when the match is operating on a corrupt data message from your WH1080 sensor being supplied to it via xap-serial. Let say that wndavg is nil from the data:match due to bad data.
sensor['windavg']:setText(wndavg*2.24)
I can't save you from your own mistakes if you do this. I would suggest that you wrap all arthimetic operations in guards to catch these issues. This can be as simple as if its NIL then default to 0 the framework will handle the nil string cases for you now
wndavg = wndavg or 0
sensor['windavg']:setText(wndavg*2.24)
pressure = pressure or 0
sensor['pressure']:setText(pressure/100)
Brett
10 January, 2014 - 20:52
#15
Running OOK code on RFM12B 433mhz Moteino
Mark
I have jumped threads as you mentioned this was the newer one.
I am currently using moteinos (lowpowerlab.com) as the basis for a sensor netwrok. I am pretty new to this and am starting out with a few temperature sensors around the house and some power monitoring with an emonTX (openenergymonitor.org). At the moment the data is getting fed back to a Raseberry Pi running emonCMS from openenergymonitor.
I am also using a separate RPi and PYWWS to grab the data off of the 1080 (a Maplin N96GY branded version) where it gets posted to a small web page care of the a Weather by You template http://weatherbyyou.com/index.php. The goal is to try and grab the 1080's data and push this into emonCMS - as well as integarting things I will gain a cloud back up to some degree as RPis have some SD card failure issues (yes looking at moving a HDD install is on the card as well)..
From the first post here do I take it you are using the Jeelabs modding of the RFM12B? http://jeelabs.net/projects/cafe/wiki/Receiving_OOKASK_with_a_modified_RFM12B
Did you go with a 150uF cap or something else as I have seen a range quoted elsewhere in the Jeelabs forums?
What sort of range are you getting with your set up?
I am a complete novice to coding and at the "just about managing to follow the code (well at least until it goes all HEX on me) and can tinker with the settings" stage.
I have seen you mention about integrating your 1080 and CC code. Have you come across the Jeelabs work in putting togther a general decoding framework for OOK signals? It is a bit spread around their website but the code is here https://github.com/jcw/jeelib/tree/master/examples/RF12/ookRelay2
Would this be of any use to you in trying to integrate the scanning for the 2 signals?
Thanks for the inspiration to keep going - I thought I had dead ended at all the code being for 868 mhz units.
Gary
13 January, 2014 - 10:02
#17
Sketch
Ah yes, make that 150pF and not 150uF. Have just looked at this cap and man they are small. I have done some 0805 SMD soldering before and they look like bricks compared to these (0603?). Time to get some bits order - CPC Farnell seem to be pretty cheap at the moment for things like this as they have no minimum order for free shipping.
As I am reduced to grabbing some time at weekends for tinkering I had a quick go at uploading the sketch you kindly reposted with a moteino holding a RFM12B 433 chip. I was not expecting this to work without the OOK mod etc but just wanted a quick trial run / tinker. I had some issues on the compiling (Arduino 1.5.5) with this looking to be Adafruit having updated their BMP library. I had a quick look at their example code and will try and update your sketch - the changes look pretty small.
Will report back once I manage to try this out for real.
By the way the plan is to try the modded RFM chip on a little shield to avoid trashing anything more if the soldering goes wrong. I am going to be using one of these handy breakout boards which I ordered up a while back as I started looking at the whole home monitoring business - a lot easier to use than the nasty 2mm pitch headers sticking off the edge of the RFM boards http://nathan.chantrell.net/20130208/rfm12b-breakout-board/
Gary
14 January, 2014 - 20:26
#18
Just another screeny from my
Just another screeny from my Corona Android app to go with Marks Tablet layout
Ignore the Image units which are mostly set as Watts i need to create my own and stop stealing marks :)
15 January, 2014 - 08:19
#19
Is it a 433 RFM12B or 868?
Mark
Is it a 868 mhz RFM12B you are using in your Jeenode (but configred with the 433 settings) or a 433 mhz part?
Many thanks
Gary
15 January, 2014 - 10:19
#20
Hi Gary, We are using 433mhz
Hi Gary,
We are using 433mhz RFMs, the majority of the WH1080 variants are 433.92mhz
Steves example on here is using the 868mhz module.
Andrew
16 January, 2014 - 21:45
#22
Will let you know how it goes
Mark / Andrew
Many thanks for the help. The bits are on the way (RFM12Bs seem to be getting scarcer)
Gary
17 January, 2014 - 10:03
#24
Hi Gary, The HAH Shop has
Hi Gary,
The HAH Shop has stock of the 868mhz version - http://homeautomationhub.com/content/rfm12b-module, i have asked Derek in the past if he would be interested in stocking the 434mhz verison, at the time he mentioned if there was enough interest this was possible.
thanks
Andrew
18 January, 2014 - 22:48
#25
RFM12Bs
I decided to order a couple more Moteinos and added a spare 433/4 and 868 (well 915) RFM12B so that I could put together a couple of little breakout boards for messing around with. Hopefully they will be with me this week and then on with the experimenting.
1 February, 2014 - 10:45
#26
Ready to do the mod
The bits and pieces have finally arrived after a slow journey through UK customs and I should get time to do the modding tonight
Mark - a quick couple of question on your sketch
For Pin_433 should this be "4" or "14" as it looks like the ref should be for Analogue 1?
On the Rf set up you have:
"rf12_control(0xA620); // A68A 433.2500 MHz"
My Maplin station has 433.9 MHz on the back - is this the same as yours? I did a quick Google and there is some suggestions that "A618" gets to 433.9.
Many thanks
Gary
1 February, 2014 - 17:15
#28
Many thanks
I had the impression that you needed to use one of the analog pins for the lead from FSK etc
As a newbie to Arduino pin 4 is Digital 4 isn't it? I am trying this out on a Uno compatible board
Gary
2 February, 2014 - 09:36
#29
And it is working
Thanks for the help. I currently am getting a nice steady stream of info out of the node.
The reception is not as good as the head unit (not unexpected) so I was tearing my hair out wondering what the issue was until I moved the node nearer a window - reminder to self try the simple things before wasting half an hour trying to work out if I had a new Maplin unit using FSK and not OOK.
Now to decide if I hook this to my RPI and push the data into the Emoncms instance I have running on that OR try and set it up as a simple Jeelab style node to send the data over the air. Time for some Googling.
I will let you now what I finish up with
Gary
2 February, 2014 - 19:43
#31
Hi Gary,Good to see you are
Hi Gary,
Good to see you are making progress, just a note, A620 is actually 433.92mhz, the comment of 433.2500 Mhz is a typo
you can verify the frequency settings on the RFM Calculator - http://tools.jeelabs.org/rfm12b.html where F=1568
I also have the maplins unit and after some initial teething issues i am now receiving reception equally as good as the stock receiver LCD unit.
i had to decrease the gain from -6 to -14 as i was picking up floods of 433 mhz data and wasnt able to parse a WH1080 packet
thanks
Andrew
21 February, 2014 - 22:09
#33
Success in sending as a Jeenode etc
Mark / Andrew
Thanks for the help. I now think I have some code working that flips the RFM12B into standard mode, squirts out the weather data in Jeelib format and then flips back to listening.
My last hurdle before I move onto adding in some more of the weather data fields to the rf packet is working out how to send out the external temp data.
Mark - it looks like you needed to heavily massage the data to get a temp. Can you point me to how I can get an accurate figure - the best I can do at the moment is to grab an integer with:
rfdata.temp_external=(get_temperature_formatted(), DEC);
I am sure the code can be tidied up a bit but here it is - if you flip on the bebug reporting it really eats up the dynamic memory!
Gary P
| Attachment | Size |
|---|---|
| Weather_shield_rf_test09.txt | 17.82 KB |
22 February, 2014 - 21:33
#36
Now with some more options added
Mark - the core is still there, just a bit of chopping and changing to match how my brain works! The rf bit is pretty self-contained consisting of: defining the data structure for the rf message; grabbing the readings to push into the rf data struct; flipping the RFM12B to transmit; and finally turning back to listening. Essentially I just dropped this in place of where you sent out the serial info
I have had a chance to have another quick play with the code and now have a full set of options for the weather station data - you just need to uncomment the info you need. Copy attached
Now just to sort out the temperature - if I go for the raw "get_temperature()" it seems to be reading too high for degrees C
| Attachment | Size |
|---|---|
| Weather_shield_rf_test10.txt | 20.81 KB |
23 February, 2014 - 16:42
#37
and it now seems to be working
looks like it is working just fine - I think it was something at the emonCMS end that was interfereing with the External Temp reading as when I turned all the options this morning it seems to be working just fine
Now to see how long I can get out a set of AAs!
I have done a little write up here http://openenergymonitor.org/emon/node/3907
The WH1080 is working well now (no doubt Brett will 'optimise' my code)
Here are the .ino and .lua I am currently using.