|
Post by Gandalph on Apr 11, 2015 18:30:14 GMT
According to several sources db level should be at around -50 RSSI. Right now I have the pi with mosquitto and RFM69HW running with abouillots latest version, it does pick up the signal from my arduino uno or pro mini fine, but only up to 4 meters or so.
I have been trying to get the signal strength up by changing from dupont cables to solid copper (22 gauge) wire soldered straight to the RFM module, up until now to no avail. Starting to pull my hear out now basically... I read somewhere about a ground plane being important for the antenna, but should surface of the RFM module should be ok for frequencies of 900Mhz and up. I will be getting the module as close on a mini breadboard as possible to see if that has any effect. Also ordered an anarduino to see what kind of send capability that has in my setup.
Tip[s are still much appreciated; having a sensor get local data without being able to send it home to the mothership rather negates the purpose...
|
|
|
Post by computourist on Apr 12, 2015 9:32:03 GMT
I don't think the antenna is causing your problems. I have used simple wire antennas and have obtained 100 meter plus coverage in open field. (868 MHz)
Right now I'm using self-built helical coil antennas (1 mm wire, 9.5 turns, 6 mm diameter, 20 mm length for 868 MHz) with good results.
An indication: my gateway is located on the ground floor, sensor on 2nd floor in a building with concrete floors. RSSI is at -74 for a stable connection.
Are you sure your power supply can deliver the required current at 3.3 Volts (130 mA) ?
Just an idea: the transmission power level can be set on the RFM69. Maybe you could try another setting using the setPowerLevel function ?
void RFM69::setPowerLevel(uint8_t powerLevel) // set *transmit/TX* output power: 0=min, 31=max // this results in a "weaker" transmitted signal, and directly results in a lower RSSI at the receiver // the power configurations are explained in the SX1231H datasheet (Table 10 on p21; RegPaLevel p66): http://www.semtech.com/images/datasheet/sx1231h.pdf // valid powerLevel parameter values are 0-31 and result in a directly proportional effect on the output/transmission power // this function implements 2 modes as follows: // - for RFM69W the range is from 0-31 [-18dBm to 13dBm] (PA0 only on RFIO pin) // - for RFM69HW the range is from 0-31 [5dBm to 20dBm] (PA1 & PA2 on PA_BOOST pin & high Power PA settings - see section 3.3.7 in datasheet, p22)
|
|
|
Post by gandalph on Apr 12, 2015 18:50:02 GMT
Yea, Eric (from the tutorial) seemed to be able to get several hunderd meters in range out of these, so I am sure they're capable. Only thing missing is knowing where I am going wrong %) I checked out the lowpowerlab library for RFM69HW, which I am using on my arduinos, they are already set to max output (31), I tried values 20 and 2, both to no effect. //in RFM69.h: _powerLevel = 31;
the Uno I have the sensor attached to is powered by 9v and usb(for serial output). The Uno has enough power coming in, however I do use a logic level converter since the Uno is 5V only (and not the required 3.3v for the RFM69HW). Not sure that has any effect on the number of milliAmps that can be provided to the sensor. edit, just checking out the specs for the 3.3v pin of the board which I bought an Uno R3 It seems this board has a max of 50 mAmps to provide to the 3.3v pin! I had not considered this before (...) but this might be the kicker.... On the other hand; the pro mini I have, I hook up to the usb port only (5v), also did try a 9v battery once, but still low RSSI values. The pro mini does seem to support output of 150 mAmps, so still not sure whats wrong. edit2: some more testing with 2 AA batteries hooked up directly to the RFM module did nothing to increase RSSI according to serial output on either the pro mini, or the R3 Uno. Serial.print(radio.readRSSI()); For good measure, I did order a buono, switchable, with 300mAmps output straight away (note to self: don't try to outsmart the tutorial and buy stuff you know jack about...) computourist: as indicated on your repo you seeem to be using a 47uF and a 100nF capacitor the 3.3v power in line?
|
|
|
Post by selcouth on Apr 13, 2015 14:12:05 GMT
I checked out the lowpowerlab library for RFM69HW, which I am using on my arduinos, they are already set to max output (31), I tried values 20 and 2, both to no effect. //in RFM69.h: _powerLevel = 31;
Try using radio.setPowerLevel in your Arduino sketch rather than adjusting the header file. It needs to be after radio.setHighPower(); radio.setHighPower(); // only for RFM69HW! radio.setPowerLevel(20);
|
|
|
Post by computourist on Apr 13, 2015 18:05:42 GMT
edit2: some more testing with 2 AA batteries hooked up directly to the RFM module did nothing to increase RSSI according to serial output on either the pro mini, or the R3 Uno. Serial.print(radio.readRSSI()); Did you connect the batteries to the RFM module at the Raspi or the Arduino side ? radio.readRSSI gives the reception strenght, so at the Arduino (end node) this will get you the Transmission level of the gateway. The battery should then be used at the Gateway side to read effects. computourist: as indicated on your repo you seeem to be using a 47uF and a 100nF capacitor the 3.3v power in line? Yes, The 47 uF capacitor is a standard capacitor for the output of a (AMS1117) voltage regulator and improves transient response for fast load changes. The RFM69 data sheet specifically states to use decoupling capacitors, as shown in the reference design, where both 100nF and 10 nF in parallel are suggested.
|
|
|
Post by gandalph on Apr 17, 2015 18:50:25 GMT
Finally some progress! computourist: thanks so much for the insight that "radio.readRSSI" is actually reception strength, I figured that it should be send signal strength! I put the Pi on hold and started working to get 2 arduinos talking to each other. I have the pro mini now working over fairly long distance with the test scripts from Anarduino T-node and gateway. These are pretty simple scripts, reception of -60db through 2 concrete floors, so exactly what I need! The R3 Uno is acting as a gateway and currently does not have to send much. I also tried the Lowpowerlab gateway and node scripts, but that does not work (yet). May be due to the ack send/rcv between the gateway and nodes that is incorporated in these, which would require the gateway to have some sending power as well (which mine does not ATM). (inputs appreciated though) Next step is to get the Pi back in the mix, to act as both gateway and openHAB server. Lesson learned: make sure you have enough mAmps on the 3.3v VCC output pin for RFM69HW, as it requires up to 130mA! thanks ps selcouth: exactly how I tested the signal strength output, thanks for the tip though!
|
|
|
Post by saback on Oct 6, 2015 23:03:40 GMT
Hi Everyone, I'm working now to adapt the project to my needs and I want to know if someone has some tips.
Current Setup: The current system is working with the original setup Nodes + Arduino Gateway + OpenHAB/Raspberry Pi with MQTT and OpenHAB.
I want to change to:
Raspberry Pi running MQTT and OpenHAB with RFM69 directly connected to the Raspberry Pi together with a second transmitter/receiver to support ASK modulation. The Hardware is ready and working at the Raspberry Pi and I can send and receive using the ASK with PiLight and I can receive through the RFM69 but I am using the piGateway daemon from github.com/abouillot/HomeAutomation/tree/master/piGateway which is listening but is showing erros because of the size of the payload.
My question is:
Does anyone has a similar setup or have a deamon working with the latest version of the nodes?
Many thanks for everyone on this forum!!!!
|
|
|
Post by mothpaul on Oct 24, 2015 21:03:01 GMT
I'm not sure if anyone has been able to get my bi-directional code working from my descriptions. I forked the original repository a few weeks ago and added my changes. abouillot has since made changes to his gateway code and libraries, so my code is no longer based on the current version, but it does work in my system. because my code is no longer based on the latest revision, i doubt it will be pulled back into the main repo. If anyone is interested in downloading my version, or using it to add modifications to the new gateway code, you can grab it from here: github.com/joshuarobot1/HomeAutomation/tree/joshuarobot1-patch-1Thank you joshuarobot, I have just gotten your bi-directional Gateway up and working - it is receiving the data from the sensor nodes I had previously established. That part is working great. I did create a few openHab items with which to send MQTT messages to the gateway and the the gateway shows the messages have been received and have been sent to the node, e.g,: -- got message @ 1642: (2, QoS 0, !r) 'ON' -- sent message to node 16 I am stymied with producing a node sketch which will receive the payload. I tried some of computourist's sketches, but they seem to use a different message structure than the one I have been using successfully. Serial Monitor also shows the sketch repeatedly dealing with "invalid message structure. .” upon my sending the MQTT message from openHab. My question/request is for a very simple node sketch that will receive the 'ON' or 'Off' payload I am sending from openHab and print it to the Serial Monitor. Do you have one or could you direct me to one? Thank, RB
|
|
|
Post by ubertastic on Jan 10, 2016 16:05:12 GMT
I set up pigateway. its working allright. but i dont know how to send mqtt message to turn a light on which is connected to digital pin 7.
i tried from raspberry ssh with the following command. but no success.
mosquitto_pub -h 127.0.0.1 -p 1883 -t mymosquitto:1272 -m "ON"
any help will be appreciated.
thanks
|
|
|
Post by autofreak on Jan 11, 2016 21:09:09 GMT
hey.
Try this
mosquitto_pub -h 127.0.0.1 -p 1883 -t RFM/101/12/7 -m ON
|
|
|
Post by acekrystal on Aug 26, 2016 16:39:12 GMT
I got piGateway working on a Odroid C1+ field nodes I used are Adafruit Metro Mini and Adafruit Feathers. Using RFM69HCW 433Mhz. Will post some update later on. I'm going to build ~7 - 25 of these setups, so i guess you will be hearing more of me about problems I'm facing Looking forward to it.
|
|
|
Post by acekrystal on Aug 28, 2016 12:26:26 GMT
After some stability problems I have it now working stable for a few day's and nights.
After some experimentation I found the following to be a solution for me: + Setting the pinmode of the NSS to OUTPUT, and doing a software pulldown + Adding a 2.2K resistor between the SPI_CLK pin to GND. Only a software pulldown did not seem to work. 10K resistor was also not enough.
|
|
|
Post by acekrystal on Aug 29, 2016 12:09:25 GMT
Found some new interesting information I think: The Adafruit RFM69HCW breakout chip works fine with a 2.2K resistor between the SPI_CLK pin and GND (on Odroid C1+) A bare RFM69HCW chip (just the green stuff without support electronics) seems to not work with 2.2K, I needed to go down to 1K in order to even start it. Now seems to work fine with a 1K resistor between SPI_CLK pin and GND. (on Odroid C1+) Details: I used an Adafruit RFM68HCW breakout board for most of my test. This board has a 5v/3v regulator + levelshifter, so i don't have to worry about debugging with an already burned chip (as I did in the past >.<). But I'm now building multiple setup to test reproduction, streamlining my guides, and testing what happens with multiple network ID's at the same location.
As I have only 1 Adafruit breakout and a ton of bare RFM69HCW chips I was forced to connect a bare chip itself without breakout board and regulations. Somehow this did not seem to work (again -.-). After lotsa debugging I found out the 2.2K pulldown resistor between SPI_CLK pin and GND was not enough. I use a 1K resistor now and all seems to work fine now. I played around with more WiringPi settings, trying to get inprovements thought a software pulldown function, but these don't seem to have any effect. I also coudn't measure any difference in voltage between pulling it up or down in the software. It could be the SPI function is overwriting these settings. But I'm unsure about that.
I'm getting kinda curious now if this is an Odroid related problem, so I guess I might buy myself an RBPi soon just for testing
|
|
|
Post by acekrystal on Sept 13, 2016 11:21:55 GMT
Update:
We are getting pretty far with our (what we started calling) SensorHub. A python script combined with a (MySQL) DB that lets you connect and log sensors pretty easy and dynamic. We are running multiple Odroids now with piGateway. For the moment we stick with the limited [14][6][2] coding [moduleID][DeviceID][SensorVar]. And do a conversion to our own [100001] SensorID structure in the DB. In the future we will try to rewrite the piGateway so it can handle more dynamic SensorID's and maybe intergrate some logic with a connection to the DB where the meta-data is for those SensorID's.
We are running for multiple day's already and are able to log lots of data already from different 433 modules. We are still working on stability as we had a *** stack smashing detected *** in the piGateway script this morning for the 2nd time in the last 2,5 weeks.
Will post some more updates here now and then.
|
|
|
Post by acekrystal on Oct 17, 2016 21:41:15 GMT
Neeext Update: So it has been some time already and lots has happened. We have fixed our Python SensorHub scripts (it had a MySQL session timeout problem) and are running stable now together with the Database. My home is running everything stable now for about a month, with 2 sensor modules pushing results every second. At the office I'm running 5 sensor modules that push results every second each, but this seems to touch the "not so stable parts" in the gateway script causing some problems as can be read here: homeautomation.proboards.com/thread/190/pigateway-returns-sigsegv-segmentation-fault. I'm hoping we can find a fix for this. Though it seems to be a tough problem so I'm looking for dirty backup plans first, like making a watch dog that just restarts the script every time it crashes. So for now the whole thing seems to start taking off. But there is still lots to be done in the comming weeks. For the time being we created a demo / prototype page to visualize some data we are currently making. At the moment you can see it here: treco.coreon.nlWe are currently building a management interface to have easy control over the db and in the future also all the scripts and sensors connected to it. There are plans to do things like pulling latest configurations or even code from the DB / web interface, for example to update the interval time, listener/pre-processor code, or even arduino code from your web browser. Most awesome would be to dynamicly construct code-pieces together from the type of sensors your selecting. I also made a quick visualization of how our data flow is looking: At the moment we still use the 4 digit DeviceID's, but we think we are going to get rid of this structure. We are aiming for a structure where there is no logical structure needed in the ID's anymore. The structure and related data should only exist in the DB making for a more dynamic enviroment. And here are some pictures At the moment we have 3 gateway's running, but we are building 6 more for the proof of concept in different houses, resulting in a total of 9 gateway's and ~30 sensor modules to play with (or maybe smiley suits as well). The first five! Inspired by Rainbow dash! More sensor modules, now with CO2 sensors, and the demo Gateway, also reading the P1 port, Electricity pulse counters, water pulse counters, and warm water pulse counters. I'm really really hoping all keeps going in the right direction and to not encounter to many problems . If someone has some general advice or idea's, or someone willingly to help with the gateway stack smashing problems, please let me know! I can maybe help you get up and running to the point where we are now. I try to document as much as possible, and we are also looking into automating a parts of the SensorHub installation to make it more easy to do. Greetings, AcE Krystal
|
|
|
Post by lucidbuddha on Nov 4, 2016 21:08:35 GMT
Trying to get a basic Temp/Humidity sensor connected.
I've got Openhab, Mosquitto and abouillot's PiGateway running on my raspberry pi. I don't think the gateway is working. When I run it, I simply get "Connect return 0". The only reference I can find is:
mosquitto_destroy(m);
(void)mosquitto_lib_cleanup();
if (res == MOSQ_ERR_SUCCESS) {
return 0;
} else {
return 1;
}
I'm a noob and have enjoyed this project thus far. I know mosquitto is working and I've got a switch in Openhab on my mobile that publishes "ON" and "OFF" respectively to the terminal when subscribed.
My node appears to be working and broadcasting at 433mhz. Serial Monitor in Adruino software shows temperature/humidity readings every 2 seconds. I feel like I'm close but have hit a wall with "Connect return 0". Please advise.
|
|
|
Post by papa on Feb 1, 2017 16:14:02 GMT
While appealing, the topic of this thread seems to lead to difficulties.
IMO the better way to go is either of two computourist approaches 1) the Gateway - End Node approach or 2) the WiFi connected End Node approach & then use the Raspberry Pi for OpenHAB / MQTT
For the time being, I'm unpinning this thread from the sticky list at the top.
If you have good reasons for handling this differently, let me know.
|
|
|
Post by acekrystal on Feb 7, 2017 23:20:33 GMT
Soo....It has been some time, and I had some time this evening for a quick update on the Pi <--> RFM69 and the whole part of a project I'm running. In short: It works-ish! We have tested, edited and fixed a ton of small and big problems we had in the whole project. Some problems turned out to be to big to fix in the time we had, so we had to use some dirty work-arounds to give us a still good and workable solution for a Proof of Concept test run. At this point we have build an other 6 new Gateway+sensor sets (now total of 9 sets) witch are now build into houses in the Netherlands for a 1 year test run. After setting everything up and tested it in our office it was pretty much plug and play by the 3rd party in the assigned houses. As-side from some K30 startup issue's related to power draw of the K30 CO2 sensor at plugging in causing the K30 to not alway's start up, everything else is working great and so far already 3 month without failure in the 433Mhz system. A few examples of problems we encountered that might be helpfull to others to tell about: PIR getting triggered by the RFM69 transmission. //solution: canceling the induction in the wires leading to the pir sensor. K30 gave a to big power draw spike. //solution: added more caps, yes yes I know we build everything in breadboards, but in the time and budget we did not have the time to create propper pcb's, we also needed to swap from Adafruit feathers to moteino's because the feathers were not in stock anymore. 433Mhz field sensor would give random incorrect data out over a random time. //solution: This is a really difficult problem that we did not manage to solve yet. All the time we thought it was a problem in the gateway script on the RBPi (Odroid C1+) related to interrupt and bit-shifting problems. Aside from some other characteristics the chance of a module failing increased by having more field sensors pushing 433Mhz messages in the air. Instead of throwing more hours at it then we already did I decided to put some extra effort in making the gateway good accessible from remote so we could fix this problem even after installation in the remote houses. But in the last week of inhouse testing we discovered having multiple field sensors giving incorrect data to the Gateway, but restarting one of the field sensors would make that particular field sensor give valid data again. This would mean the problem is at the field sensor side, what we coudn't (yet) update from remote. So at that point we decided to let every field sensor restart itself every hour. It is dirty, but proved quick and effective, and with the sensors we are using on these field sensors we would not miss any crucial data. If a PIR would trigger, the atmega would hare restarted before the PIR is going low again. Testing with damaged modules. // At some point we started to have very simmular problems again with one of the gateway's not receiving messages or starting up the RFM69 chip, like it was not making proper contact all the time. After hours of testing it turned out problems where getting whore and totally random. At the end it turned out this module was once connected incorrectly to a hot-water sensor by an other, shorting the Odroid C1+, causing it to degrade over time (long after the shorting problem was fixed) to the point where it wouldn't even boot from the SD-card. These kind of things happen, but are a real pain is they start with showing problems that look like something you had solved already. I had a bunch more challenges, but I don't remember them all right now, I might look through the documentation I made at some point to share some more problems and solutions. Anyway, for now it all seems to work great, I'm using it also in my home and have homey turn on and off things in my home based on input from the field sensors. (I let the homey subscribe to the mosquitto channel/topic on the gateway). The database and the python listener/per-processing software we created is also working great. An other company related to project Treco build a simple API on top of our database to let a high school, university and some other company's access that data for further analysis over the coming year. A few friends, my boyfriend (who all helped building this) and I are really happy with how far we have come, and are looking for what we are going to do now. We have noted a lot of things that still need to be done, and new features we like to put into it, but at the moment most of us are taking a break from this project. Of course I will keep all the current operating Treco sets running for project Treco. For myself I'm still working on getting loads more (field) sensors in my house for measuring mostly ~16 temp/humidity points of my home on all walls/roof on inside and outside. So I will keep on fixing small things. Currently I'm on a side project solving my power distribution to power all the sensors in a simple way that I could re-use in other projects. I'm designing my own PoE module for this, it is still work in progress for some time, but you can find it here already. A few things that I would like to do with this project, but where I need some help from my friends or others: - Deploying the current setup has a long guide that needs to be done, we would like to make a clean package that people could just pull from github, install, easy configure and run it. - In line with above, we would like to rework the whole RFM transmission protocol to be more dynamic. Ultimate we would like to have all sensor scripts in the database, and let a new field sensor join through a simple default script that will request all the needed sensor scripts, names, ID's and other configuration through a simple pairing process through a web service on the gateway(database). - Remove structured ID's and let the gateway/database be in control of what meta-data (human readable meta data like name, place, type, accuracy, interval time.. etc. of the sensor) should be related to the next generated ID. This will remove a lot of limitations for the amount of sensors within one type (like temperature) or different types (I believe currently max is 9) being used and having to know all the corresponding correct ID structures for every type of sensor / expected data payload the gateway expects. - Come up with a plan what the best way is to give this back to the community. - Join forces with existing UI platforms. I think the best road this can go is to be an additive/module/package for an existing platform like OpenHab. Where we can focus pure on connecting sensors based on an other network that WiFi, in this case 433/868/915 and maybe even Lora versions of these. And here are some pics for who is interested in what it looks like: (left: Inside of the gateway, with also the screw terminal for electric and warm water usage measurements. Also smart metre P1 port cable. 3D printed frames where used for mounting the computer and breadboard to a DIN35 rail.) (middle: Gateway as finished box, with installation guide on the left side, and a laser-cut cooling and semi-transparent window for led status readout.) (right: all the 6 sets on the ground, 4 field sensors p/gateway, and the demo/test board on the left.) I learned a ton from this project, and I hope this gives me a good slingshot into the world of IoT .
|
|
|
Post by papa on Feb 8, 2017 0:42:39 GMT
acekrystal, I wondered how your work is going. Thanks for reporting all the details on your progress & difficulties you encountered.
Congratulations! It sounds like you've gotten much further on this version of the DIY Home Automation project. Others before you hit big snags.
I might be able to help with that documentation, presupposing I get enough information from you & the right parts to test things with the documentation. Good documentation would help with giving back to the community.
I'll Personal Message you about another possible help for a need you listed.
|
|
|
Post by acekrystal on Feb 8, 2017 8:08:38 GMT
Hi papa (that is strange to say btw... I get why you choose that name... haha!) Thanks for your reply! I will see your PM and get in contact with you. And I need to say most of the credits also need to go to all the people that made there code available for everyone. Big credits need to go to: electronichamsters on www.instructables.com/id/Uber-Home-Automation-w-Arduino-Pi/I learned a lot from him and I think thanks to him lots of development and enthusiasm was created in this direction. It was strange though that I only found out about him after I had been searching the web already for many months. So I really need to link his work abouillot on github.com/abouillot/HomeAutomationHe made a awesome great start with the (Pi)Gateway to run on Linux. I did not even change much in his code, though we spent hours debugging it and making notes of problems/weaknesses it has that should be updated in the future. We also made it work on an Odroid C1+ as we preferred that above the RBPi. But I left the RBPi option intact and should work just as good because I know it is still by far the biggest community. computourist on github.com/computourist/RFM69-MQTT-clientAlthough I did not use any of his code, I still admire what he does and he gave me some good input/idea's And all other people that helped/motivated me
|
|
|
Post by Peterlesbou on Nov 1, 2017 10:30:21 GMT
|
|
|
Post by papa on Nov 1, 2017 23:15:04 GMT
Thanks, Peterlesbu for the information
|
|
|
Post by papa on Jan 9, 2019 15:31:03 GMT
Jan 8, 2019 0:31:06 GMT -6 alex said: Hello, I was wondering if I need Raspberry Pi, why not run gateway node on it using something like this www.kittley.com/2018/04/05/blog-rfm69-pi/ and this jeelabs.org/2015/05/20/rfm69-on-raspberry-pi/ Is it possible? What are the downsides? Thank you, Alex =================================== papa: Alex, I'm moving your message to this thread so anyone can see, respond, & benefit. Different members & guests have inquired about doing this & maybe some suggest they made progress, but I don't believe anyone has documented it here on this forum. It's a while since I considered a Pi Gateway, especially since I'm fine with a separate RFM69 Arduino Gateway. I believe one downside was that the higher power, longer range RFM69 radio may need more current than the Pi requires. When I get a chance, I'll look at the links you referenced. Does anyone else have thoughts on a Pi Gateway? Can anyone document a success on this?
|
|
|
Post by papa on Jan 9, 2019 23:40:11 GMT
Alex & others, I believe I have seen the Jeelabs stuff before, but probably not the two kittley offerings. The python code & documentation here might be a previously missing piece that could make this work. I note that one kittley offering says, "This is the high power version which will draw more current than an RPI can supply when it is in high power mode. So we will reduce the transmission power in the code." The first sentence in the quote confirms what I remember. So far in the python code, I do not see the transmission power being reduced.
Alex & others, I encourage you to give this a try & report back on your results.
|
|