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=t5orCcrySp8
Thanks Papa.... Again. I updated the sensor assignments and am now getting the correct MQTT outputs.
// 47 Hall Sensor // 52 Current sensor // 68 IR flame sensor // 69 MIC sensor // 70 MQ Gas Sensor // 71 Vibration
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.
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.
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?
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.
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.
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.
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.
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 sensor All are self-explanatory accept the SERVO_SWING which will allow one to actuate to a specific location and back with a simple ON command.
All done!!! I'm happy with the product (attached) and all new node have been successfully tested. I've updated both the Arduino and Moteino codes with the following:
Arduino & Moteino versions // 17 servo sequence: (JA Added) D8 read/set servo to swing to a specific position and back to another position. // 47 Hall Sensor (JA added) D3 // 64 light intensity via photoresistor (papa added, June 2017) A0 // 68 IR flame sensor (JA added) A1 // 69 MIC sensor (JA added) A5 // 70 MQ Gas Sensor (JA added) A2 // 71 Vibration (JA added) A4
papa: Scanning Joshua's sketch versions ^^, I believe he added his sensor code to two versions of the same Multi-Choice Node sketch. The "Arduino" version is later & I don't believe the "Moteino" version has anything new for the Moteino. I recommend you go here for my latest version of the Multi-Choice Node sketch which now includes Joshua's sensor code & credits. For reference, I leave Joshua's sketch versions above.
sensor fritzing diagram.pptx (856.55 KB) << This PowerPoint file provides wiring diagrams for the added sensors & links to other useful info like other needed parts.
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.
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.
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.