|
Post by Admin on Sept 16, 2017 2:15:12 GMT
Hey, Just wanted to post to say that I've given papa more admin rights to manage the organization of the forum. Sorry I haven't been active since starting the forum, kids keeping me busy. Really cool to see people building stuff! Eric
|
|
|
Post by Admin on Feb 15, 2015 18:22:51 GMT
I just put up Release 2 of the MQTT gateway/node on github.com/computourist/RFM69-MQTT-clientChanges: - increased payload size to 32 bytes - changed integer in payload to long integer - defined standard devices and device numbers; these are implemented in the gateway, so no more need for gateway changes when adding standard devices/nodes. - implemented uptime counter in node & gateway - implemented version reporting in gateway - removed leading spaces in decimal sensor value - check for empty MQTT-message; this evaluated to 0 in earlier version - error checking & reporting - Computourist I'll sticky this one and unsticky the previous post - that sound good?
|
|
|
Post by Admin on Jan 27, 2015 1:20:11 GMT
OpenHAB for me has been a finicky unpleasant piece of software to work with. I have a hard time getting good feedback from the program as to whats wrong ... I wonder if the "received command CLOSED" ever happens? Is it an issue of it not happening on a timely manner, or not happening at all? This would be a good question to post on the OpenHAB google group, actually. groups.google.com/d/forum/openhabNot sure I ever pointed this forum out. It's the main place place for English speakers on OpenHAB issues.
|
|
|
Post by Admin on Jan 23, 2015 3:10:32 GMT
The RFM69 library uses AES encryption, so it's pretty difficult for anyone to take apart your transmission or send you modified data. However, it's possible (even if it's unlikely) that they could do a replay attack. It's possible to capture your data, and without decrypting it, simply re-broadcast it.
Back when I started the gateway code, I had plan to use the "unsigned long" int to be used as a counter of sorts. The gateway would keep track of each sending node's counter value, and each transmission should be larger than the previous received transmission. The sensor nodes would know to increment this value. This would prevent replay attacks, since the attacker can only replay a previously recorded signal, they can't take it apart and resend it with an incremented counter value.
volatile struct { int nodeID; int sensorID; unsigned long var1_usl; // increment this value on every transmission float var2_float; float var3_float; int var4_int; }
I would also have to build in some means of resetting the counter value (either on start-up or counter roll over). So if the counter value is 0 AND both var2_float and var3_float have values of "123". Or something like that. It's not bullet proof, as the attacker can still capture this special reset transmission, but it's an improvement.
The gateway could keep track of "current" counter values for each nodeID & sensorID pair in a 1000x10 matrix. Where (<nodeID>,<sensorID>) forms a coordinate into the matrix, and the value stored in the matrix is the current counter value. Zero out this counter value when the special reset transmission is received. And simply don't post MQTT data if message is received whose counter value isn't greater than the (X,Y) value. Some lead way might be needed in case the reset transmission isn't received by the gateway, which I was going to solve by enabling the ACK.
Well, never got around to implementing this. But perhaps someone will want to work on it. Or have a better idea for doing this.
Eric
|
|
|
Post by Admin on Jan 23, 2015 2:54:12 GMT
This is really exciting. I want to try this out too. BTW, if someone wants to draft up a post that summarizes how to do this, I'll unsticky this thread and sticky the new post. I would help to link to this thread so people can see the process.
Awesome!
|
|
|
Post by Admin on Jan 21, 2015 2:49:38 GMT
Well, at least I can cross off the inverter possibility for now. The MQTT link stability between the Arduinos and the broker has always been an issue. With Eric's dual gateway design there were always disconnections, but he wrote code that would re-establish the connection whenever it would go down. It works pretty well, though I think the gateway can miss transmissions if they occur while it's re-establishing the link. Same issue with Abouillot's unified gateway. It would drop the MQTT connection periodically and his solution was to check for and reconnect to the broker periodically. In my experience, the brokers worked perfectly; I could communicate with them always through other means, like MyMQTT. I always suspected there was a bug in the pubsubclient library, or that we just weren't using it properly. Your gateway though, as far as I can tell, is not dropping the MQTT connection. It looks to me like it's just locking up while sending or receiving using the RFM69. Sometimes on the first transmission, sometimes after eight or nine. Sometimes the radio led remains on as if it crashed before it got to the part of the sketch that tells it to turn back off. I don't think it's a MQTT issue as the gateway serial monitor stops showing any activity. Typing the commands you implemented in your gateway sketch produces no response, and resetting the node so it sends it's "I'm alive" signal produces no response on the gateway serial monitor either. -Demondreamer That's totally true. I don't know the MQTT library for Arduino well, and just pieced together the reconnect portions based on what I was seeing. When I tried the sample code that came with the knolleary MQTT library, I think I was seeing the same type of sporadic disconnect issue. I thought the "loop" call in the code was suppose to fix any disconnects, but it didn't seem like it was. There was even a time when one Wiznet module seem to have more disconnect issues and another Wiznet module was almost getting none...so I don't know what the root cause is. I wish there was a bullet-proof example of using the MQTT library out there, and I do have a suspicion I'm using it wrong. Or there's a bug...but it's the only Arduino MQTT library so I hope not. This thread is really interesting, thanks for all the info. Eric
|
|
|
Post by Admin on Jan 21, 2015 2:35:41 GMT
Thanks! I agree, you've got to put a stake in the ground and stop the analysis at some point. It's a constantly moving target; I'd just started down the path with 315MHz when I learned of the ESP8266 hitting the scene. I don't consider that chip an option for my stuff because WiFi is too power hungry and heavy-duty for long-life battery applications, and this chip is too limited for more advanced uses. But a $4 WiFi module has a lot of appeal for many applications. One of the more interesting things is that it has scripting and general-purpose I/Os, so no micro controller is needed for very simple sensor applications. To your point, while I'd like to nerd out and code in assembler on raw chips and do my own radio encoding, I've opted to use Arduino for its speed of development. I suppose I should do similar with the radio module to get started. Shifting back to finer points of your project, did you specifically select the frequency and baud rate based on your applications needs, or was it more a case of "this works well enough, let's move on"? Just wondering if there are factors I should consider that I may have overlooked. Cheers, Richard ESP8266 is pretty interesting. I read about a working MQTT library for it. It's tricky though - once you use wifi, you start having to deal with the overhead of wifi and making it work stably. It'd be an interesting transceiver to use for powered nodes, but it might be a few more months until the wifi library gets easier to use and more stable. I haven't seen any ~300MHz receivers with the same set of benefits as the RFM69HW. I also did not fine tune the baud rate on the RFM69 I'm using. It's just default - no doubt it can go farther if the baud rate is lowered, but the default was more than adequate for home automation.
|
|
|
Post by Admin on Jan 15, 2015 0:46:52 GMT
That's awesome! I've never gone back to debug why I needed two Arduinos for the gateway. I see you got the radio.setCS(RFM_SS) to work. Did you have to do anything special to the RFM69 library? Or did you just use the library as is from lowpowerlab and only needed that line to make the interrupt work? You did a lot of work around disabling interrupts and stuff to make it reliable. That's pretty huge. Thanks so much for sharing this. Eric Hi, The instructable article inspired me to build a simular setup. I have now an Arduino based gateway working in duplex mode. This means messages get passed from end node to MQTT broker and vice versa. End nodes send sensor data, but also receive instructions for end node control and actuator control. Code is on: github.com/computourist/RFM69-MQTT-client
|
|
|
Post by Admin on Jan 13, 2015 1:13:59 GMT
Yes, I think that's the case. I use the 5V for sensors/outputs that need 5V for power, but leave the switch at 3V so I don't break the RFM69HW. I'm not 100% on this, but setting the switch at 5V may also make the Arduino IO pins all communicate using 5V. On the Buono R3 Arduino clones I use there's a 3V pin header and a 5V pin header that output that regardless of the switch setting. I always have the switch set at 3V and if a sensor requires 5 (like the ultrasonic range sensor), I'll tap off the 5V header to power it only. Try testing the IO lines with a volt meter. -Demondreamer
|
|
|
Post by Admin on Jan 13, 2015 1:11:23 GMT
Hey, thanks. I'll sticky this.
|
|
|
Post by Admin on Jan 6, 2015 4:48:22 GMT
Well, not much progress. Still struggling to get the garage door sensor node working. I had a moment of success... I have a spare radio, I guess I'll sub that in and see if it makes a difference since I have ruled out the sensor and arduino as being defective. Are you using a 3.3V Arduino? Just trying to think of obvious things.
|
|
|
Post by Admin on Jan 6, 2015 4:46:02 GMT
Did you put the "email bundle" in your addon folder?
Pretty much every feature in the openhab.cfg file requires that you copy the corresponding addon java file into the addon folder.
|
|
|
Post by Admin on Jan 6, 2015 4:42:55 GMT
I'm curious why you picked the 900MHz range over the other alternatives like 315 or 433. ... Cheers, Richard Hi Richard, All of those are good points. It would be nice to be able to define the exact parameters for the ideal home automation transceiver. But realistically, you have to use the chips that are out there, in the form factor that you can handle, and not spend the rest of your life developing a library for the chip before being able to build anything useful . At $4 per transceiver, and with a couple of Arduino-clones built with this transceiver available, I thought this was the best option at the time. I've read about the ESP8266 after starting my project. At the time, there wasn't much info on deep sleep and how wifi handles waking from sleep. Good sleep performance was one of my major requirements for battery powered sensors, so I went ahead with the RFM.
|
|
|
Post by Admin on Jan 4, 2015 21:19:52 GMT
Hi Eric, I think that your project is awesome and am planning to re-create it and make some changes to suit my needs. I have some of the basic components needed but have ordered the rest and should arrive end December. ... It seems like this guy has had some success with bi-directional communication or am I mistaking?: Bi-directional communicationThank you for the great work... Oh man, sorry I didn't see this earlier. Thanks for pointing this out. This looks like a very sophisticated network layer for the nRF24L01's. I don't have the skills to make something this sophisticated. I wonder if it's possible someone would port this over to the RFM69HW's. It's also possible to have both wireless chips used depending on the criteria. But this is awesome for home automation, much better than the setup I've come up with. Glad to see so much development in inexpensive wireless transceivers.
|
|
|
Post by Admin on Jan 1, 2015 3:22:48 GMT
Thanks for your feedback! As with anything this complex, there's a ton of little things that don't appear in any of the tutorials. Thanks for sharing what you ran into and how you solved it. Hope things go well.
|
|
|
Post by Admin on Dec 31, 2014 1:36:11 GMT
Hi. The "setup" (gateway) is what connects the battery powered reed switch to OpenHAB. There's other options (see the sticky thread about using RFM69 directly on a Pi), but you'll need something to translate the wireless data to MQTT.
|
|
|
Post by Admin on Dec 23, 2014 3:30:11 GMT
Have you tried this yourself? It doesn't seem to give me a reading when I use 5V. No, I haven't tried pro-minis. I'd be interested if you find a good way around the issue. I don't have any better ideas than what you've mentioned - separate 5V reg.
|
|
|
Post by Admin on Dec 13, 2014 23:58:19 GMT
This is the follow up thread for my question in the comment section on the original instructables project (http://www.instructables.com/id/Uber-Home-Automation/?ALLSTEPS). Thanks for the great tutorial and for setting up the forum, Eric! The goal is to replace the gateway of two Arduinos in the original project with a direct connection between the Raspberry Pi and a RFM69 chip. I will try doing that by using an RPi port of HopeRF's Arduino library by Eric Trombly (https://github.com/etrombly/RFM69). Thanks for trying this out. I haven't had time lately to keep working on it, but I'm very interested in what you find out. Once you get this working, bi-directional comms should be easy to implement, so it takes care of quite a few items. Let us know! Edit: made this a sticky thread. Alexandre Bouillot has also done some work on this. I think he's actually created a port of the Arduino gateway in Raspberry Pi and included etrombly's python library? This might get you started quicker. github.com/abouillot/HomeAutomation/tree/master/piGateway
|
|
|
Post by Admin on Dec 13, 2014 23:51:14 GMT
Does anyone have a good source for temp sensors of the DHT type that work at 3.3v? The batch of dht22's that I got will only work at 5v. Why do you need 3.3V DHT22's? Can't they run off the 5V rail, even if the Arduino is in 3.3V mode?
|
|
|
Post by Admin on Dec 6, 2014 5:32:55 GMT
(Placeholder for list of compatible devices)
|
|
|
Post by Admin on Dec 6, 2014 5:32:04 GMT
|
|
|
Post by Admin on Dec 6, 2014 5:31:07 GMT
Use this board to post questions about rooting the wink hub, doing local control, and adding devices to the wink hub. List useful information and blog posts on the web.
|
|
|
Post by Admin on Dec 6, 2014 5:19:55 GMT
I want to summarize information and provide a place for collaboration on projects using OpenHAB and Arduino with RFM69HW wireless transceivers. I started using Arduino, RFM69, and OpenHAB to build a bunch of cheap home automation sensors. I made a gateway based on MQTT, but there's some limitations. Although I intend to keep working on it, life gets busy and I think other people are making improvements. So I wanted to provide a place to gather up the knowledge. Also, use this forum to ask questions. Moderator (papa): This forum now uses an improved RFM69 communication that computourist provided.
In an effort to make this forum as efficient as possible, please try to utilize some of this convention for questions. Put the [Question] in the forum topic when you have a question, trying to solve a compile error, etc... Then go back and edit the original post and replace the Question with "Solved" to indicate your problem has been solved. I'd like to find a way to help new people get started faster, perhaps select between different options for gateway code. I don't really have the time to do a thorough job of testing different people's code and generally administrate any central code base. Perhaps this could be a crowd source thing where we vote for the best gateway code and a few bullet-proof sensor code. So, that's what I'd like to get out of this forum at some point. But, also keep in mind it's difficult having your code judged, so show a little sensitivity. Lastly, I selected this proboards site just from some quick googling. Hopefully it meets our needs and isn't too cumbersome or loaded with advertising. If someone is willing to help moderate/administrate this forum, please let me know. Basically, watch for good threads that should be stickied. I haven't been keeping up with my hobby as much as I'd like. Here's a link to my original Instructable on using Arduino-RFM69-OpenHAB Moderator (papa): Again, the Uber communication approach is not compatible with how this forum now does it. On this forum, most of the Uber Home Automation features have been adapted to this forum's approach.
|
|
|
Post by Admin on Dec 6, 2014 3:57:56 GMT
There are tons of home automation forums out there. This forum exists to concentrate on a couple of specific topics. One is home automation using Arduino, OpenHAB, and RFM69 wireless transceivers. Another is the hacking work around the Wink hub. These reflect stuff that I'm doing personally, so other might get added. I'm not sure how long term these topics will be. Technology changes so fast, especially in the area of home automation. Feel free to suggest other categories and technologies that don't already have a place. I'm not trying to replicate forums that already exist. I'm just trying to fill a hole, provide a place for the community to discuss topics when there isn't a public forum for it. the homeautomation.proboards.com forum is categorized into separate boards. Go up a level to see these boards, and the topics inside them. Use this board (http://homeautomation.proboards.com/board/1/general-board) for suggestions for adding other boards, or if you feel another board fits within what we're doing, suggest a link.
|
|