Joshua
Junior Member
Posts: 75 
|
Post by Joshua on Feb 11, 2018 16:31:32 GMT
arduino_node_Mgf_updated_v2_2.ino (78.32 KB)
papa: ^^ Later versions of this sketch are linked below
Hello folks, ^^ This is my first attempt in adding sensors to the multi-choice end node. Another guy (not in the forums) and I came up with the attached code. However, the MQTT output is not matching the serial output. You can see below that the last 3 values (73,75,76) are the same as the value from 71. I also made a video of what is happening www.youtube.com/watch?v=t5orCcrySp8Here's the added sensors // 69 Current sensor // 70 IR flame sensor // 71 MIC sensor // 73 MQ Gas Sensor // 75 Vibration // 76 Hall Sensor Serial Output MQTT sub
|
|
|
|
Post by papa on Feb 11, 2018 19:23:23 GMT
Joshua, good for you that you are experimenting with adding other sensors. I will have a troubleshooting look at your code, but I will be limited by not having those sensors. In the meantime, have you looked at my thread about the process of adding new features to the RFM node possibilities. Particularly notice this post about how the device numbers are sorted into ranges according to data input & data output & type of data: integer, real or floating point (has decimal), string. That is, to work with the Gateway's data structure, one must match the device number to the data of the sensor or other device. One clue for troubleshooting is that all device numbers above 70 get the same value, namely 68, the value read by 71, the first value above 70. According to this table, device 71 is the last integer input device. Devices 72 & following are for string transport. It looks like (except for device 71) you may be using device numbers in the wrong range for your sensors. |
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Feb 11, 2018 22:02:45 GMT
Thanks Papa.... Again.  I updated the sensor assignments and am now getting the correct MQTT outputs.
papa: Joshua, glad to hear your good results above. Below, I included your new sensors code in the latest node choices sketch & gave you get credit for documenting the new sensors. In the latest node choices sketch, I added the default Arduino pins for each sensor.
I'm moving discussion of your following comment to another related thread.
Joshua: Has the group considered how to incorporate multiple devices with similar outputs within the sequencing? i.e. my devices 68-71 are all pretty much the same thing with the analog reading. Seems inefficient to denote each one as I have done.
|
|
|
|
Post by papa on Feb 12, 2018 15:28:07 GMT
Joshua: "Has the group considered how to incorporate multiple devices with similar outputs within the sequencing? i.e. my devices 68-71 are all pretty much the same thing with the analog reading. Seems inefficient to denote each one as I have done."
papa: Not that I have seen in forum interaction. You'd have to ask computourist why he chose to structure the RFM Gateway / Nodes this way. (& computourist seems a busy guy that we've not heard from for a long while.)
Perhaps inefficient, but it has been very effective & reliable. For human & machine parsing, some kind of system is needed to keep track of each piece functioning on a node. Changing the system risks further confusing people who struggle to get the stuff communicating at all.
The way the system is, you have been able to put 6 sensors on one node. Even with using 4 analog input devices, you still had 4 more integer input devices available in the 64-71 range. Moreover, you could have moved some sensors into the "real input" devices (decimal values). The way the system is, I've been able so far to make two pretty complicated devices: Irrigation automation & cooking controller. Anyway, the more we put on one node, the more we risk having enough current & the more we risk functions interfering with each other.
If you want to explore changing the system, you might look at the ESP8266 WiFi node sketches which communicate somewhat differently (but so far have only a few functions coded). They also use "devices". However, since they communicate directly with OpenHAB (no need to comply with gateway parsing), they would not necessarily restrict the data types sent by each device, but would require the OpenHAB entries to handle the data type properly. Seems like one would still need something like separate devices to keep track of what function is talking.
Hmm, perhaps by inefficient, you mean that for each new device of a certain data type, we end up with similar sections of code. Could we somehow use one section of code to handle the same data type & still use devices or something to track which node feature is talking or receiving commands? Perhaps. Perhaps using the ESP8266 node method of constructing a message in a buffer string. Perhaps at least some repetitive coding could be handled by a function. Perhaps something like this would appeal to those of us that put a lot of features on a node, but not confuse things for people just getting started.
Does any one else have ideas?
|
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Feb 12, 2018 19:30:59 GMT
Yes. However, I'm trying to shy away from depending on WIFI for connectivity. Basically, I have 4 nodes that can all run on the same code and now the block of integer input devices (64-71) are full in the choices code.
// 47 Hall Sensor. D3
// 52 Current sensor. D3
// 64 light intensity via photoresistor, int. data: A0.
// 65 sump status, int 0=ok, 1= stuck low ?, 2= too high ? A1 & A2
// 66 water level, int 0x=stuck low?, 1x= safe middle, 2x= safe top, 3x= too high. data: A3, A4, A5. power, D7.
// 66 leak status, int. data: A3. power: D7 (same device as water level)
// 67 soil moisture, int. data: A0. Power flips between D6 & D7. changed from orig D7 & D8.
// 68 Reed Order status, Garage Door, D6, D7
// 68 IR flame sensor. A1
// 69 MIC sensor. A5
// 70 MQ Gas Sensor. A2
// 71 Vibration Sensor. A4
This may be the case of making perfect the enemy of good as one can just repeat the device number as I did for 68 knowing these devices cannot be enabled on the same node.
// 68 Reed Order status, Garage Door, D6, D7
// 68 IR flame sensor. A1
JA
|
|
|
|
Post by papa on Feb 12, 2018 20:47:45 GMT
Joshua: I'm trying to shy away from depending on WIFI for connectivity.
papa: I did not mean to use ESP8266 wifi devices. Rather I meant, to the RFM69 code, perhaps adapt the communication style of the ESP8266 sketches.
Besides, the ESP8266 devices are not well set up for adding sensors.
Joshua: One can just repeat the device number as I did for 68 knowing these devices cannot be enabled on the same node.
papa: Yes, one can certainly do that, just as one can use an Arduino pin for different purposes on different nodes.
|
|
|
|
Post by computourist on Feb 12, 2018 21:44:51 GMT
Hi papa and @joshua, I am indeed very busy in my job, but there is always time to peek at this forum every now and then. To respond to you question: the message structure is a result of very early discussions on this forum. We could then hardly foresee the way nodes would be used and tried to anticipate as much as possible. To overcome limitations of this structure there are several possibilities: 1- build another node; Prices of Arduino and RFM are low so this solution is not that far-fetched. 2- change gateway code to support a different message structure. This would break backwards compatibility and would not be my first choice. 3- change the node code, but stay within the current structure. There are multiple ways to achieve this. Some examples: - Use two variables to indicate a single input. One variable would indicate sensor group, the other would indicate the sensor within the group. To read a sensor you would first send an integer to select the sensor group , then send the sensor-ID. With only 2 integers you could address 100 sensors in this way. - Emulate multiple nodes on a single Arduino. A single node could use two different node-ID's to address sensors. This would double the amount of sensors that can be used for each node. I think the effort to implement the last solution would be limited, so maybe you could give it a try. Please let us know the outcome, as I am sure others on this forum would benefit. Especially when papa does such an excellent job of replying to questions and guiding newbies. Have fun ! - Computourist. |
|
|
|
Post by papa on Feb 13, 2018 0:06:14 GMT
Awesome, computourist. It is so good to hear your perspective, your suggestions, your continued interest in the forum, & your compliments.
Your perspective echoes & expands my concerns (especially backwards compatibility). If changes are made, possibility 3 would be my inclination. Thanks for the creative suggestions for that.
If we try such suggestions, we will certainly document what results we get.
|
|
|
|
Post by papa on Feb 13, 2018 1:39:41 GMT
Joshua, the sketch you provided above includes a servo option, but you did not mention it. Is the servo aspect of the sketch working? Latest Node Choices Sketch & Initial Customization (Updated Aug. 30, 2021) In the above ^^, I included Joshua's work on sensors into the approach I use for the computourist choices sketch. I also added some explanatory notes. I activated each of the new choices & confirmed that they compile without error. In other threads, I documented using the sensors & servo to test the code. Joshua, I hope you will test this latest choices sketch & report your results.Joshua & I have started discussing more documentation for adding the new features to our RFM69 nodes. |
|
|
|
Post by papa on Feb 13, 2018 21:24:57 GMT
Again, Joshua, please use the sketch in my last post & test your sensor code in it.Also, Joshua, I was asking for a parts list & schematic & I got to thinking maybe I could get parts list from Eric Tsai's Uber Home Automation Instructable. The Uber sketches & OpenHAB entries work differently from what's now in the forum, but sensor information should still be useful. Proposed Parts List & Links to Possible Examples Prefer sensors that will work with 3.3 volts so your Arduino compatible can run at 3.3 volts & not damage your RFM69 radio.Hall SensorMic Sound SensorAnalog Vibration SensorIR Flame sensorMQ2 gas/smoke sensorCurrent TransformerServo motor
See Joshua's parts list in this post below.
|
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Feb 15, 2018 13:52:28 GMT
Sorry for the delayed response. I've been incorporating the changes into the Moteino code and cleaning up the Arduino code. I still believe these are in draft form. My hope is to perform a final test of each new device this weekend as I could have made errors while cleaning up things. Here's the latest device list with the associated pin and voltage: // #define SERVO_SWING / D8 5VDC via a 3 wire servo
// Adjust the following to your specifications. Search for text strings below without quotes.
// "int swingVal =" (value from 0 to 180)
// "for (swingVal = 10; swingVal <= 70; swingVal += 1"
// "for (swingVal = 70; swingVal >= 10; swingVal -= 1"
// #define SERVO // D8 5VDC via a 3 wire servo
// #define HALL_SENSOR // D3 3VDC via hall effect transducer (Omnipolar Magnetic/Hall Sensor SS451A preferred)
// #define PHOTORESIST // A0 3.3VDC via photoresitor
// #define CURRENT_SENSOR // D3 5VDC via CT Current Sensor
// http://www.homautomation.org/2013/09/17/current-monitoring-with-non-invasive-sensor-and-arduino/
// #define IR_FLAME_SENSOR // A1 5VDC via 4 wire analog IR sensor
// #define MIC // A5 5VDC via 4 wire analog Sound Sensor
// #define MQ_Gas // A2 5VDC via 4 wire analog MQ series gas sensors
// #define VIBRATION_SENSOR // A4 5VDC via 4 wire analog vibration sensorAll are self-explanatory accept the SERVO_SWING which will allow one to actuate to a specific location and back with a simple ON command. |
|
|
|
Post by papa on Feb 16, 2018 2:34:22 GMT
Joshua, I look forward to hearing your results from testing each new device. As I said earlier, I'd like to incorporate the new devices code into the latest choices sketch.
|
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Feb 18, 2018 20:05:49 GMT
|
|
|
|
Post by papa on Feb 19, 2018 14:49:53 GMT
Joshua, thanks to you, sunbloquer, & brump, we have a nice expansion of node features on this forum. I appreciate your efforts & sharing those efforts with us. Did you check the possible parts list I put in this post? |
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Feb 19, 2018 15:29:06 GMT
I updated My Post with the parts list. papa: Thanks for the parts list, Joshua,
& thanks for the Fritzing schematics in the Powerpoint file above (sensor fritzing diagram.pptx). |
|
|
|
Post by papa on Mar 20, 2018 15:18:55 GMT
A Caution about Fritzing schematics in the Powerpoint file above (sensor fritzing diagram.pptx)Joshua, again you have added several sensors to our project & have provided important information & coding for that. Now having more time to study the schematics, I have two concerns: 1) The schematics are shown on a standard (5 volt) Arduino Uno, maybe because the Uno was more available in Fritzing. 2) Some sensors are shown as connected to 5 volts on the Arduino. To avoid damaging RFM69 radios, we can only connect the radios to 3.3 volts. Unless hacked, a standard Uno runs 5 volts not only through the 5v socket but also through the digital pins which connect to the radio. Ways to address this concern if using an RFM69 radio to send these sensors' data to OpenHAB: 1a) Use an Arduino compatible that (like a Buono Uno) can run at 3.3 volts through its digital pins. 1b) As I said with my parts list above, get sensors that can run at 3.3 volts. OR 2a) Use a 5 volt sensor with a standard (5 volt) Arduino Uno, BUT 2b) use an RFM69 Breakout Board like this, instead of a bare RFM69 radio. These breakout boards' electronics can handle 5 volts from a standard Arduino Uno. Note: I have only used approaches 1a & 1b, but other forum members have recommended approach 2a & 2b.
|
|
|
|
Post by papa on Mar 31, 2018 14:39:29 GMT
Updated Multi-Choice Sketch with New Code for Added Features & RFM69 Transmissions Joshua (& brump),
computourist_node_v2.2MhC_choices_pub.ino (107.49 KB)
I have scanned your latest versions of the Multi-Choice Sketch & compared them with what was my previously latest version ( a few thousand lines of code). I believe I mostly followed what you provided & accurately merged your code into the version posted just above. However, I believe I corrected some errors & made some clarifications. I also changed some device numbers used to decrease collisions between functions with the same device numbers. This sketch version above includes code for sensors that Joshua added above & also brump's latest code in this thread (now including txRadio() corrections & Dimmer.h changes). This sketch version includes my recent code for setting a default value for the actuator (LED, Relay), disabling failing RFM69 radio transmission & re-enabling them (& how to handle actuator values when transmissions resume). Joshua & brump, please test your code in the above sketch & report back your results. My thanks for your attention & contributions.
|
|
brump
Junior Member
Posts: 81
|
Post by brump on Apr 1, 2018 10:00:37 GMT
Papa,
Thank you for taking the time to dedicate your time to this project.
It was very good!
I just tested all the functions on my board, everything is working perfectly.
papa: Thanks, brump, for the code & for testing & reporting your results. Good to work with you.
Now I hope to hear from Joshua to see if his code works in the Multi-Choice Node sketch.
|
|
Joshua
Junior Member
Posts: 75
|
Post by Joshua on Apr 9, 2018 1:12:02 GMT
I made a good run at it with good results. No problems here. Super clean!!!!
|
|
|
|
Post by papa on Oct 22, 2018 19:26:13 GMT
Thanks, again, Joshua, for the code, schematics, & your efforts to check its merging into my Multi-Choice Node Sketch. I appreciate your ongoing contributions to this project. Since I'm considering using the VIBRATION_SENSOR to enhance one of my projects, I've looked more closely at its documentation above. A correction may be needed above in sensor fritzing diagram.pptx in the VIBRATION_SENSOR fritz. There you have the sensor's VCC pin connected to Arduino A4 & the sensor's DO pin connected to Arduino 5 volts. Is that correct? ... Did you intend to connect sensor AO to Arduino A4? According to sensor specs, it can operate on 3-5 volts so I believe we'd could connect sensor VCC to Arduino 3.3 volts or 5 volts, right?
VibrationSensor_Joshua.ino (347 B) << I began testing the board using this sketch adapted from Joshua's RFM69 contributions. I connected sensor DO to Arduino A0 (Joshua used A4), sensor VCC to Arduino 3.3v, sensor GND to Arduino GND. (My vibration sensor board has only 3 pins & no AO pin.) I did not use the board's potentiometer to change the sensitivity. While running the sketch & watching the Arduino IDE Serial Monitor (SM), I rested the Arduino-connected sensor breakout board on a Dremel type tool. When the Dremel was off, SM showed "Vibration : 30" When the Dremmel was on & making vibrations, SM showed "Vibration : 1023"
So with the above correction to connecting the sensor board to the Arduino, Joshua's Vibration Sensor code in the Multi-Choice Node sketch should work.
|
|
|
|
Post by papa on Oct 30, 2018 21:59:00 GMT
I created a detailed Vibration-Sensing RFM69 Node thread that documents building & programming the node. That thread will also document turning the device into a Vibration Timing Node. |
|
brump
Junior Member
Posts: 81
|
Post by brump on Sept 26, 2019 9:46:14 GMT
spam!!!
papa:yes, I removed the spam. have been less available lately.
|
|
I updated the sensor assignments and am now getting the correct MQTT outputs. 
