|
|
Post by papa on Nov 11, 2021 20:08:41 GMT
Not Needed: Connection to RFM95 Reset PinIt turns out that resetting the RFM95 radio is not needed. So the ESP32 & Arduino compatible no longer need connection to RFM95's reset pin. Accordingly, I updated the sketches so far posted in this thread. This applies to these linked sketches: Struct Server Struct Client ESP32-RFM95 GatewayThe upcoming Node sketch will also contain this change. Next, Programming & Customizing an RFM95 Node
|
|
|
|
Post by papa on Nov 11, 2021 20:49:24 GMT
Programming & Customizing an RFM95 Node R95_choose_nodes_MhF9r2_pub.ino (137.17 KB) << Members, download this Node sketch & open it in Arduino IDE. Do NOT upload it until you customize as follows. Save your work as you go. Note: When you change a define in the Gateway sketch, change any matching define in the node sketch & vice versa. For example, if you UNcomment #define SECRET in the Gateway sketch, also UNcomment it in the Node sketch. If you want to use encryption, UNcomment #define SECRET. Also into the same folder as the node sketch, copy the two encryp.x files from this post & see an additional change below. Find #define NODEID 85 & for sake of demonstration, leave it as is. Later, this is where you give each node a unique identifying number. Find 3 lines with #define RF95_FREQ & according to your radio's frequency, UNcomment (remove initial //) only one of the lines. Find #define User_Installed_RFM95. UNcomment for user-installed radio. Comment (start the line with //) for ESP32 with pre-installed radio. If you installed the radio, find #define RFM95_CS & #define RFM95_INT (RFM95_RST is not needed). Make sure the pin assignments are correct.
Find #define Fahr & #define Cels. Uncomment only one.
Find & UNcomment #define HT. Find & UNcomment #define ACTOR
Find & UNcomment #define DS18. Skip a line & UNcomment #define DS18BFind #define NetworkOne & leave it UNcommented. Find ifdef NetworkOne. If you're using encryption, change the encryptkey (16 elements separated by commas, each element starts with 0x. The given encryptkey is too easy to guess. If & when you add NetworkTwo or NetworkThree, complete encryptkey as you did for NetworkOne. Next, Configure Arduino IDE & Upload Node Sketch
|
|
|
|
Post by papa on Nov 11, 2021 20:54:35 GMT
Configure Arduino IDE & Upload Node Sketch
With the Node sketch (last post) open in Arduino IDE & the Node device connected to your computer's USB, configure Arduino IDE as follows ...
In Arduino IDE Tools/Board menu, select Arduino AVR Boards then (if possible) select the name of your board or a working equivalent. At the least, select Arduino Uno.
Tools/Port: Select the port that the computer/Arduino IDE assigned to your Arduino compatibl.
Check your work. Upload the Node sketch to the Arduino compatibl.
Next, RFM95 Gateway & Node, Expected Results
|
|
|
|
Post by papa on Nov 11, 2021 21:08:32 GMT
RFM95 Gateway, Expected Results from Working Node
With the ESP32 Gateway connected to computer's USB & the ESP32 Gateway's port selected in Arduino IDE Tools/Port, open the Serial Monitor & see something like the following continue from the Gateway results displayed above :
The above represents the Gateway receiving successful communication from Node 85. The data is limited because sensors are not connected.
Next, RFM95 Node, Expected Results
|
|
|
|
Post by papa on Nov 11, 2021 21:21:14 GMT
RFM95 Node, Expected Results
When Working Gateway & Node Are Communicating
With the Arduino node connected to computer's USB & the Node's port selected in Arduino IDE Tools/Port, open the Serial Monitor & see something like the following displayed from the node:
Next, OpenHAB & RFM95 Node Communicating Via the Gateway
|
|
|
|
Post by papa on Nov 12, 2021 21:39:16 GMT
OpenHAB & RFM95 Node Communicating Via the GatewaySucceeding with the above (Node communicating with the Gateway) is significant, but not very useful. However, with openHAB, we can collect data from a node (via the Gateway) & we can also communicate with & in some regards, control the node (via the Gateway). To install openHAB, see this thread. Especially see adding the MQTT Binding, For adding Things & Channels, see starting here. You will need to adapt from those openHAB posts as follows. Those posts are about Node 05 & if you followed the above instructions you created a Node 85. Your node85 has these devices & a Node85 Thing will need these channels: 00, 02, 04, 09, 16, 48, 49, & 50. Next, An Example of Adapting a Channel
|
|
|
|
Post by papa on Nov 12, 2021 21:52:19 GMT
An Example of Adapting a Channel
From Node05 to Node85
This post gives one example of adapting a RFM69 Node05 Channel to a RFM95 Node85 Channel. This should help you adapt the other channels.
In the Add Channel Window, fill the fields with configs: (RFM95 Node85 version)
Channel identifier Node05Channel16 >> Node85Channel16
^^ arbitrary ? as long as we match it in a linked Item (see below)
Label Node05_Switch >> Node85_Switch
^^ arbitrary ?, make it useful for yourself, but not too long
Channel type On/Off Switch >> No Change
^^ choose type compatible with the device/channel data type
MQTT State Topic home/rfm_gw/nb/node05/dev16 >> home/r95_gw/nb/node85/dev16
MQTT Command Topic home/rfm_gw/sb/node05/dev16 >> home/r95_gw/sb/node85/dev16
Click [Create] to save your configs
Next: Create Item to Link to Node85's Channel 16
|
|
|
|
Post by papa on Nov 12, 2021 22:00:21 GMT
Adapt Item to Link to Node85's Channel 16 This was the instructions for Node05. In an .items file, create an item entry based on the following. However, replace my channel UID with your channel UID determining it like in this post. This would be instructions for Node85. In an .items file, create an item entry based on the following. However, replace my channel UID with your channel UID determining it like in this post. To display the item's data on HABPanel, use a Switch widget. Next, Many Node Possibilities
|
|
|
|
Post by papa on Nov 13, 2021 19:31:56 GMT
Many Node PossibilitiesNow that you have a working RFM95 Gateway, it can communicate with several more nodes. With an RFM69 Gateway built with an Arduino & an Ethernet shield, I've used about a dozen nodes. I did not try more than a dozen so that Gateway may have handled more nodes. I would think that an ESP32 RFM95 Gateway could handle a dozen or more nodes. The RFM95 choose_nodes sketch above has mostly the same coding (mainly except radio-related code) as the RFM69 choose_nodes sketch. Both sketches have many sensor & other functions that can be activated by UNcommenting (remove // at the start) sketch lines that start with #define. This forum board has detailed threads on building, customizing, & programming nodes with these sensors & functions. This post lists & links various node projects. With some adaptation, most RFM69 node code & instructions should work for RFM95 nodes. I'm not sure whether over the air programming is up to date. I briefly tested the SLEEPY function which seems to work. I'm just not sure the code takes full advantage of obtaining the lowest power drain. The schematics for RFM69 node projects can be used without change with RFM95 nodes. (especially since we don't really need to connect the RFM95 reset pin.) In general, when programming nodes, use a unique NODEID for each node & be careful to avoid using an Arduino pin number for more than one purpose. For setting up openHAB to communicate with your node, use hints in posts starting here to help you adapt RFM69 node instructions to RFM95 nodes. Next, How Far Can RFM95 Devices Communicate
|
|
|
|
Post by papa on Nov 13, 2021 20:00:29 GMT
How Far Can Our RFM95 Devices Communicate?
So far, instead of uni-directional antennas, we use plain wire antennas so our distance will likely be less than optimum. I'm not sure about installing a uni-directional antenna on an Arduino, but a hack might help the plain wire antenna. I believe some ESP32 boards have the option of using a uni-directional antenna. Perhaps that would help even if a node did not have a better antenna. I suspect that a uni-directional antenna could help reach some nodes & make it worse with other nodes. We might need more than one RFM95 Gateway (or RFM69 Gateway) to reach all our nodes.
I hope to do some testing. How does distance & obstacles & antenna affect your RFM95 communication?
Next, Powering Our RFM95 Devices
|
|
|
|
Post by papa on Nov 13, 2021 20:52:02 GMT
Powering Our RFM95 DevicesFor the ESP32_RFM95 Gateway, we'll probably use mains power via a 5vdc USB adapter or via a USB breakout board. Perhaps place the Gateway at a mains outlet where the Gateway can reliably connect to WiFi. For Arduino_RFM95 nodes, we can use mains power in our buildings or other locations that have such power. We may want to place nodes at a distance where mains power is not available. In that case, use battery power. Connect a battery or battery pack's negative terminal to an Arduino Gnd pin. Connect battery's positive terminal to Arduino VIN pin. For an Arduino with an Arduino Uno form factor (2 x 2.5 inches) & USB connector, perhaps use 7 to 12 volts DC. Basic Moteinos & MiniWireless do not have the power drain from the USB circuit. For a Moteino, its company suggests 3.3 to 9 volts DC connected to VIN & Gnd. The MiniWireless' company suggests 3.3 to 7 volts. The node sketch's TXinterval variable is presently set at a maximum 60 seconds between sending data, but data also may be sent when it changes. Increasing TXinterval (send data less often) might reduce battery drain. Using the choose_nodes sketch's SLEEPY function should decrease battery drain significantly & the function's code might be better tweaked. The Loops variable now counts a sleep period of 8 loops of 8 seconds (64 seconds). Loops could be increased to lengthen the sleep period & reduce battery drain. For any node function that is on/off, #define MAIL or #define SWITCHIRQ probably offers the least battery usage. Those options put the node to sleep until a change in the Arduino D3 (interrupt) pin wakes up the node to send data. For more, see here & here & here but remember these instructions need some adapting (see posts earlier in this thread). Personally, for a long distance node, I believe I'd battery power a MiniWireless or Moteino (without USB). If possible, I'd also use the MAIL or SWITCHIRQ options. What is working for you (& not) in powering remote nodes? How will you use the RFM95 devices?
|
|
|
|
Post by papa on Apr 27, 2023 19:55:54 GMT
Update, WiFi_RFM95 Gateway, Using Secondary SPI Bus
I worked out how to implement gateways on ESP32 boards where the primary SPI bus is not available (like the HiLetgo OLED ESP32).
The following posts will document necessary changes in wiring & coding.
PS If properly customized the Gateway code below should work on an ESP32 board that uses the primary SPI bus (e.g. Sparkfun ESP32 Thing).
Next, Wiring an ESP32 Gateway for the Secondary SPI Bus
|
|
|
|
Post by papa on May 2, 2023 21:04:42 GMT
A Two-Way RFM95 Gateway with WiFI & MQTT, Secondary SPI BusThe following wiring diagram for the two way RFM69 Gateway (version 2) is similar to one above, EXCEPT the RFM95 radio is connected to the ESP32's secondary SPI pins. Especially for when the Gateway will be disconnected from the Serial Monitor, one steady-burning LED will signal that WiFi/MQTT is connected. The flashing LED signals when radio communication is happening. For each LED, the originally shorter pin goes into an ESP32 ground. Each originally longer pin goes into the ESP32 pin designated in the Gateway sketch. For hints about parts, code libraries, etc., see posts starting here. Disregard references to ESP32 pins (primary SPI bus). As able, you may change the ESP32 pins for the LEDs, but you must also change the pin numbers in the Gateway sketch (see below). Unfortunately the HiLetgo OLED ESP32 board seems to have limited pins available.
On May 2, 2023, the wiring diagram was updated. The RFM95 DIO0 was moved from ESP32 pin 5 to ESP32 pin 25 because ESP32 pin 5 is an I2C pin used for the mounted OLED.
 << Members, click on pic for larger view. Next, Prepare to Program the ESP32-RFM69 Gateway, version 2
|
|
|
|
Post by papa on May 2, 2023 21:08:07 GMT
Prepare to Program the ESP32-RFM95 Gateway, Version 2
Latest Version
^^ Corrected public version, May 2, 2023 ^^ RFM95 DIO0 interrupt pin moved from ESP32 pin 5 to ESP32 pin 25
Open the Arduino IDE (program for loading, editing, & uploading Arduino sketch programs). From the Arduino IDE, open the sketch (program) file downloaded above. Accept the sketch's being put in a subfolder. Before uploading (sending) the Gateway sketch to the Gateway, you must edit it to customize to your situation. Your IDE computer must also have the additional code library files that the Gateway sketch needs. The following offers guidance.Note: In editing a sketch, sometimes we are told to "comment out a code line" which means put two forward slashes ("//") at the start of the code line to make the rest of a line a "comment" (not programming code) & disables the code. To UNcomment a line means to remove the two forward slashes ("//") at the start of the line to make the rest of the line into working code except "//" later in the line still indicates comment there. For example in the Gateway sketch, see "// #define DEBUGRADIO" which is a comment, not active code. The line "#define DEBUG // uncomment for MQTT debugging" starts with active code & ends with a comment (after //). Adapt this post to download & install the Radiohead & encrypt library files. Place the files in the same file folder as the Gateway sketch. Then to this Gateway sketch, add this customization: To use the secondary SPI bus, find the line "#define Alt_SPI" & UNcomment it (remove // at the line's start). If commented, the sketch uses the primary SPI bus. To see the related programming, search for "ifdef Alt_SPI" PS If you leave #define Alt_SPI commented, the code should work on an ESP32 board that uses the primary SPI bus.
|
|
|
|
Post by papa on May 2, 2023 21:09:34 GMT
RFM95 Nodes to Communicate with ESP32 WiFi Gateway (SPI_1 or SPI_2 Bus)
|
|
