|
Post by papa on May 2, 2018 2:20:29 GMT
Log: "Validation issues found in configuration model 'My.rules', using it anyway: The use of wildcard imports is deprecated."
papa: The imports near the top of My.rules are left from OpenHAB 1. You can delete those imports & probably eliminate the log error, but may not solve your main issue. =====================================
Log: "Validation issues found in configuration model 'My.sitemap', using it anyway: Sitemap should contain either only frames or none at all"
papa: As I believe I said earlier, you can delete the comments near the top of My.sitemap & probably eliminate the log error, but it may not solve your main issue. ====================================== Log: "Error during the execution of rule 'Node02_Sensed': An error occurred during the script execution: Could not invoke method: java.lang.Number.floatValue() on instance: NULL"
papa: As I believe I said earlier, rule 'Node02_Sensed' in My.rules combines Node02 Temp & Humidity into one OpenHAB entry. However, if openHAB is not getting Temp or Humidity data (NULL), the rule will choke on it. I believe this log entry is a symptom of your problem, not a cause. ========================================
ngy, as you show from the gateway serial monitor output, etc, "when I trigger the switch via BasicUI, the LED on the node does not light up ... nothing is logged when I trigger it via node switch, but the LED lights up. ... the gateway receives all the MQTT messages fine, switch status change is received immediately, so definitely something from the gateway to mqtt to openhab is not working/passing 'null'. ... it seems like openhab and the MQTT is not talking properly. gateway <-> node communicates well, but gateway <-> mqtt <-> openhab, somewhere along the way does not work."
papa: That's a good analysis of the symptoms: (Gateway & node are talking. Gateway is connected to local network & MQTT. Still node data is not getting through the gateway to the OpenHAB User Interface or logs, but the cause does not seem to generate a log error.) Again a good analysis of symptoms, but somehow we are still missing the cause of your main problem.
Try the deletions I gave above, & as you said, "keep diagnosing"
====================================================
I've been writing a Linux .bash script to check key areas of readiness for our DIY Home Automation project. I need to go to bed now, but I'll try to post that tomorrow for you to try. Maybe that script will indicate something.
One more thing in the log: "Started Language Server Protocol (LSP) service on port 5007." If that is the voice command aspect, you might try disabling that. I remember seeing something about that feature possibly causing some problems. ==================================
!! Hmmmmm, ngy: "Also noticed (and fixed) an incorrect use of '<' (should be '>') in My.items file, I typed it incorrectly." That is important.
Yes, correct version of the switch item is Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }
The use of '<' '>' 'sb' & 'nb' in MQTT bindings are important to what direction the MQTT messages communicate. '< & nb' says pass data from Node towards Gateway & openHAB. '> & sb' mean pass command from OpenHAB & UI to node.
The first MQTT binding asks for the state of power going to the LED. The second is meant to send any commands from openhab to the node.
|
|
|
Post by papa on Apr 28, 2018 16:13:16 GMT
ngy, As far as I can tell, your My.xxx files are almost the same as the ones I used with an openhabianpi recently. The one difference I saw: from My.rules, you can delete the line: import org.openhab.core.library.types.*
However, I don't believe deleting that line from My.rules will solve your problems.
As your log said, Validation issues found in configuration model 'My.sitemap', using it anyway: Sitemap should contain either only frames or none at all
In My.sitemap, you can delete the comment lines above sitemap My label="My House" In the sitemap, OpenHAB prefers not to have anything that is not framed by { } Or put { on a blank line before the comments AND put } on a blank line after the comments. Comments framed { } like that do not seem to generate the log error.
That deletion or framing ^^ may avoid the log error entry, but I don't believe it will solve your problem.
Error during the execution of rule 'Node02_Sensed': An error occurred during the script execution: Could not invoke method: java.lang.Number.floatValue() on instance: NULL ^^ The rule in My.rules combines Node 2 Temp & humidity. If OpenHAB is getting only NULL (no data) from temp & humidity, the rule has nothing to work on. ======================== Use this terminal command to make sure the Mosquitto MQTT message broker is still running on the PI sudo service mosquitto status
|
|
|
Post by papa on Apr 28, 2018 15:29:37 GMT
SPI - Serial Peripheral Interfacepapa: This documentation page makes me wonder if the atwinc1500 shield might conflict with some pins (CLK MISO MOSI) that the RFM69 radio uses at D11, D12, D13, but it looks like the rest of the Arduino pins needed could be manageable. brump: These pins are from the SPI interface, so all devices can be connected in parallel. Only the CS pin needs to be connected to an available digital pin. brump: Here's a good explanation of SPI: LINK
|
|
|
Post by papa on Apr 27, 2018 14:30:16 GMT
ngy: "Okay, I just needed to reboot the Raspberry Pi."
papa: Rebooting is often a great way to fix problems. I'm busy with other things for a while, but will try to offer some help.
What openhab User Interface are you using? habpanel? habmin? I've never used those & do not know if the My.xxx files would have conflicts with them. If not already you might try the basicui user interface that I use & see what results you get.
"'Node02_Sensed': An error occurred during the script execution: Could not invoke method: java.lang.Number.floatValue() on instance: NULL" ^^ Did errors like this clear up & you started seeing data in the OpenHAB User Interface you chose? Without extra programming, errors like that can happen for a while especially when openhab, gateway, & node start up & occasionally later. It means openhab is getting nothing at the moment from that piece of node data. Sometimes rebooting (even more than once) openhab, gateway, & node can get things going.
What are you using to view & edit the My.xxxx config files? Editing with a Windows-type text editor introduces end of line characters that cause problems in openhab running on a Linux device like an openhabianpi. Editing on a Windows machine should use a Linux friendly text editor like the free Notepad++ << If this is true for you, reload the My.xxx originals into an editor like Notepad++ & then edit in any changes you made to the originals.
If your effors or the above ^^ do not fix your problem, please post here your copies of My.items My.rules My.sitemap
|
|
|
Post by papa on Apr 25, 2018 15:35:25 GMT
Some Things to Consider When RFM69 or WiFi Communication Is Not Reliable Between Nodes & OpenHABzanyhunter about antenna length contributing to RFM69 communication problems: "I finally found the problem with the original radio. Weird stuff was happening with it. I could move it around, vibrate it, or anything and it wouldn't connect. It was only when I brought my finger CLOSE or TOUCHED the top of antenna where it immediately responded. Turns out that the antenna length was barely a few millimeters too short to achieve a full quarter wave, and therefore couldn't transmit a signal! Lengthened the antenna and now I have a third node that works flawlessly." Here's my somewhat researched post about antenna lengths for different RFM69 radio frequencies. Note that I've seen slightly different antenna length recommendations on various web sites. One may need to experiment with this: start antenna a little long, try communication, if not reliable, trim a little off, try communication again, etc. By analogy, with a regular radio (perhaps in a basement or otherwise "shielded" location) trying to get a weaker station, many of us have probably got better reception when we put a hand near or on what functions as the antenna (perhaps the power cord), in effect adding to the antenna. Remember communication reliability may also be affected by radio frequencies from other nearby "broadcasting" devices (cordless phones, microwave ovens, etc). It may also be affected by the building materials & distance between the "transmitter" & the "receiver." "Tuning" an RFM69 antenna as above may help overcome radio frequency competition. I find my WiFi & RFM69 communication is enhanced by placing a WiFi router or an RFM69 Gateway at the highest possible & most central possible location in my building.
|
|
|
Post by papa on Apr 25, 2018 15:26:00 GMT
ngy: "I found my problem was actually the w5100.h library. ... Once I fixed that, transmission was stable."
papa: good news
ngy: "my openhab webpage isn't opening anymore ... opening openhabianpi:8080 refuses to connect"
papa: Sounds like you mean that the openhab dashboard is not opening for you. Did you try replacing "openhabianpi" with the Pi's IP address, something like 10.0.0.10:8080?
Can you directly open the openhab user interface you have chosen (basicui?) ? something like openhabianpi:8080/basicui/app?sitemap=[your sitemap] or 10.0.0.10:8080:8080/basicui/app?sitemap=[your sitemap] If you can open it, is it showing results from the nodes?
For that dashboard to respond, openhab 2 must be running. The following command should tell you: sudo /bin/systemctl status openhab2.service
|
|
|
Post by papa on Apr 25, 2018 12:24:17 GMT
ngy, did you also see zanyhunter's post about antenna length contributing to RFM69 communication problems: "I finally found the problem with the original radio. Weird stuff was happening with it. I could move it around, vibrate it, or anything and it wouldn't connect. It was only when I brought my finger CLOSE or TOUCHED the top of antenna where it immediately responded. Turns out that the antenna length was barely a few millimeters too short to achieve a full quarter wave, and therefore couldn't transmit a signal! Lengthened the antenna and now I have a third node that works flawlessly." Here's my somewhat researched post about antenna lengths for different RFM69 radio frequencies. Note that I've seen slightly different antenna length recommendations on various web sites. One may need to experiment with this: start antenna a little long, try communication, if not reliable, trim a little off, try communication again, etc. I suppose communication reliability could also be affected by radio frequencies from other nearby "broadcasting" devices. "Tuning" the antenna may help overcome radio frequency competition.
|
|
|
Post by papa on Apr 25, 2018 12:11:48 GMT
good troubleshooting, zanyhunter. Your discovery about antenna length adds another thing for users to check when gateway/node communication is not reliable.
|
|
|
Post by papa on Apr 24, 2018 2:16:56 GMT
ngy, 1) When you built the Gateway, did you do this hack to protect your RFM69 radio from 5 volts? 2) When you programmed the Gateway, did you use this post about Downloading, Editing, & Installing Libraries. It contains two important library edits that help make gateway <> node communication reliable. If the above items 1) & 2) ^^ were already ok or if fixing them makes no difference ... RFM_MQTT_GW_25_pub4.ino (15.95 KB) << 3) Here is the slightly earlier Gateway version 2.5 to download. Customize that Gateway 2.5 sketch as necessary, upload to your Gateway unit, & try communication with the node. Let us know if that works better & if not, report your Serial Monitor results.
|
|
|
Post by papa on Apr 22, 2018 12:44:29 GMT
Thanks, brump, for answering that concern. Best wishes on receiving the unit & making a working WiFi gateway. Keep us posted on your results.
|
|
|
Post by papa on Apr 21, 2018 13:47:08 GMT
Excellent, zanyhunter. You're welcome. I'm glad you got things working. That's a powerful feeling, isn't it. AND often things go better after getting the first RFM69 gateway & node to communicate with each other. I wish you well in adding other nodes.
By the way, as you did, having spare parts & substituting them one at a time is a good troubleshooting technique.
I'll mark this thread as "Solved"
|
|
|
Post by papa on Apr 19, 2018 9:55:40 GMT
zanyhunter: "I noticed it would give random data like that whenever I moved the wires around... I wonder if that's the problem"
papa:could be you have a short or loose connection somewhere. RFM69 radios are a bit power hungry & could act up if not getting steady power. Often some little thing is the final problem to solve. I also believe you are close.
Thanks for the updates on your construction & programming & library edits. Those should be right.
You are welcome. I'll let you know if I think of other things to check.
|
|
|
Post by papa on Apr 18, 2018 0:19:57 GMT
zanyhunter, welcome, sorry you having trouble with DIY Home Automation via RFM6 radios. Most of us do at the beginning.
I am traveling at the moment & will have some set up time when I arrive, but I'm taking some of my end of day time to give you some response.zanyhunter: "My current Switch code is: Switch Act_Node02 { mqtt="<[mosquitto:home/rfm_gw/nb/node02/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node02/dev16:command:*:default]" }" I rechecked my code. You are using the same mqtt binding code as I use for several nodes & they work just fine. I believe I learned doing this item with a double binding (the first checks the device's status & the second passes any commands to change status) from greginkansas. I also believe that the version greg gave you is a longer version of doing the 2 mqtt bindings I provided.zanyhunter: "I finally got a successful and stable connection between a bare-bones end node and the gateway. I am now able to read the RSSI and Voltage values from within OpenHAB2." papa: That does sound promising.zanyhunter: "I just noticed something really strange. If I look at the serial monitor of the gateway, all is happy. Receiving voltage, RSSI, and current switch states. But, if I look at the serial monitor on the end node, it continuously says "no connection". Does that mean that it is only sending data, but not receiving it?" papa: That is strange. Without knowing more, I can only guess what would cause that & ask questions that may seem to have obvious answers ... When you get the strange results are BOTH the Gateway & the Node powered (via computer USB or wall adapter) AT THE SAME TIME?
zanyhunter: "I tried actuating the ACTOR switch (D9) on the node using OpenHAB. I see the gateway's serial output display "MQTT-Topic: home/rfm_gw/sb/node02/dev16", however the node never sets the output to high and always returns the MQTT message "home/rfm_gw/nb/node02/dev16: OFF". I already uncommented "#define ACTOR" papa: You said you got a working bare bones node (which is not yet wired for the Actuator used by the ACTOR code). From the later schematic in this post, did you add the wiring for D9: D9 to 100-220ohm resistor to long LED pin & short LED pin to ground?zanyhunter: "tried some of the other relay ports (dev 17-20)" papa: use dev 16. Without other changes in the sketch, dev 17-20 would not work.
BTW what is the full name of the Gateway sketch you are using & the full name of the node sketch you are using.
Did you follow the instructions in this post about code libraries, especially this link to make two key edits in code libraries.
Let me know your answers to the above & maybe we can rule out some things while I consider the above & your next responses. About 23 hours from now, when we've stopped for the night, I'll look for your responses & we'll go from there.
|
|
|
Post by papa on Apr 14, 2018 13:57:39 GMT
Nice work, Joshua. Thanks for the code for a new sensor. When I get some time, I'll work on merging it into the Node Choices sketch.
|
|
|
Post by papa on Apr 14, 2018 13:27:43 GMT
In this post, brump illustrates how he enclosed DIY Home Automation components in a monitor case.
|
|
|
Post by papa on Apr 10, 2018 17:37:42 GMT
brump: I found a viable solution using the module atwinc1500 of Atmel sold by approximately US$9,00. papa: Yes, as here, I saw the separate atwinc1500 module at various costs starting at $9+ US before shipping, etc. brump: "The shield for the Arduino is marketed by adafruit in two options: with antenna at the PCB or external antenna." papa: Yes, as here, Adafruit has the atwinc1500 unit mounted on a shield for about $25 US before shipping, etc. brump: The library for the module is the wifi101. papa: Yes, looks like one can use Arduino IDE to program the module on the shield. Here, Adafruit provides more info on understanding & using the shield. papa: This documentation page makes me wonder if the atwinc1500 shield might conflict with some pins (CLK MISO MOSI) that the RFM69 radio uses at D11, D12, D13, but it looks like the rest of the Arduino pins needed could be manageable.
|
|
|
Post by papa on Apr 9, 2018 11:25:59 GMT
brump, congratulations on finding a WiFi module that seems promising for our gateway. I will post here if I choose to try that module, but it will be at least two weeks before I am able.
Keep us posted on your results with this module.
|
|
|
Post by papa on Apr 7, 2018 15:21:18 GMT
Yes, brump, I've done some research also. Some challenges to overcome if using ESP8266 WiFi: ESP8266 can only run & communicate at 3.3 volts, but also requires more current power than an Arduino can supply. So ESP8266 probably needs a dedicated power supply. ESP8266 may need to communicate with an Arduino Mega which has more than one dedicated serial communication pins. (Software Serial emulation cannot handle enough communication for this.) I experimented with connecting an ESP-01 module with a Buono Uno. That worked a little, but not very well. This video explored four options to adding WiFi to an Arduino, three that failed, & one that succeeded (Arduino WiFi Microcontroller at 19 minutes & 21 seconds). However, the successful item was not available at www.robotshop.com. This search at www.robot.com offered some other options, some of which claimed to provide enough current power for the ESP8266. I'm not sure how much I will pursue this. A wired Ethernet RFM69 Gateway works well for me.
|
|
|
Post by papa on Apr 5, 2018 11:48:35 GMT
ngy: "i never installed mosquitto! I just assumed it comes with openhabian. I installed it via 'sudo openhabian-config' -> optional components, and boom. it works now. thanks!"
papa: Yes, ngy, for our forum's software to work, one must somehow install mosquitto. openhabian-config makes it more convenient than for other operating systems, but we must take that extra step within openhabian-config. Congratulations on getting that working. Now enjoy developing your DIY Home Automation network.
Thanks brump, for offering help to ngy.
|
|
|
Post by papa on Apr 4, 2018 11:33:50 GMT
brump: "I had an idea of using a wireless (WiFi) gateway for nodes with RFM69HW radios"
papa: Sounds like a good option. brump & others, let us know if you make progress (ideas or actual) on this.
Via internet search, I saw some Arduino WiFi shields using ESP8266. Would one of those be good enough?
|
|
|
Post by papa on Apr 1, 2018 19:55:17 GMT
Latest Version of the RFM69 Multi-Choice Node SketchBased on computourist's original DHT End Node Sketch, this one sketch uses #defines to select one or more possible RFM69 node functions among many choices. This latest version includes the latest code provided (& tested) by brump & the latest code provided by Joshua. Separate threads document achieving the functions & often include related OpenHAB entries. See this post for links to the threads that document the various node functions.Note: To use each thread's info on customizing the sketch, you may need to rely on the mentioned contents of a sketch line rather than the line's number. A node programmed by this multi-choice sketch also needs an RFM69 Gateway. Beginners should use this thread to get started with building & programming their first gateway & end node. At this post within the Beginner thread ... forum members may download the multi-choice sketch. (Membership only requires free registration.)
|
|
|
Post by papa on Mar 31, 2018 21:14:15 GMT
Updated Multi-Choice Sketch with New Code for Added Features & RFM69 Transmissions brump (& Joshua), computourist_node_v2.2MhF2_pub (112.73 KB) << Updated & corrected Oct. 12, 2018. 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 your latest code in this thread & also code for sensors that Joshua added in this thread. 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). brump: "line 2384 and line 2393 contains the function written as txradio();, but the correct one is txRadio();" papa: I corrected those errors. Thanks! brump: "Remember to update the pin numbers in Dimmer.h" papa: In the sketch, I listed the changes near #include <Dimmer.h> Thanks! RFM_MQTT_GW_25.1_pub1.ino (16.19 KB) brump, ^^ into this version of the gateway, I also merged your added devices 73-76. I named it ... 25.1 to indicate that it changes the Gateway 2.5 version. brump & Joshua, please test your code in the above sketch & report back your results. My thanks for your attention & contributions.
|
|
|
Post by papa on Mar 31, 2018 20:44:35 GMT
Improvements in the Cooking Controller Sketch
I previously provided an RFM21 version of the Cooking Controller sketch that is improved from earlier.
This sketch works with the same schematic above. I updated customizing instructions above for the new sketch.
The improved cooking controller will now work with RFM69 radio code included, with or without radio connection to a gateway. Without radio connection, the LCD will not show updates for about the first 5 of 60 seconds.
When radio transmission fails, the controller will disable it & then try to re-enable it every 0 of 60 seconds. When radio transmission is succeeding, a "T" shows at the LCD's right side. Failing transmission displays "-" instead of "T"
When the cooking controller is activating the relay for the cooker to heat, an "H" shows at the LCD's right side. With heat off, a "-" displays.
As HH:MM:SS, the LCD also displays either Total time since execution started OR how long the current targetTemp is Holding.
Earlier, the sketch sent OpenHAB the current temperature only at the start of a step & when the controller was holding at a targetTemp. Now the sketch also sends the current temp as it works toward the targetTemp.
|
|
|
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.
|
|
|
Post by papa on Mar 23, 2018 14:09:17 GMT
Updated Multi-Choice Sketch with New Code for Added Sensors & RFM69 TransmissionsI posted the latest multi-choice node sketch ( computourist_node_v2.2MhB_choices_pub.ino ) in this post of the thread, Building an RFM69 Home Automation Network (Beginners ??). This sketch version includes the above 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). This sketch version also includes code for several sensors that forum members have added recently.
|
|
|
Post by papa on Mar 22, 2018 18:02:15 GMT
Another Possible Arduino Compatible for Nodes At First Promising, Then Problematic. At First Promising ...ngy "I did notice a new board out, the Massduino by the same company as the Buono Uno boards. Have you tried any of them for additional cost savings?" papa: I have not tried the Massduino. The Massduino seems to have similar specs as the Buono Uno. Only differences I noticed: microprocessor, 12 bit vs 10 bit ADC resolution, & that Massduino shares 1kb EEPROM with flash memory. So the Massduino may be OK for this forum's projects.ngy: "my massduino boards came in, and they seem to operate just fine, based on my few basic sketches I uploaded to it. Looks like we have an even cheaper option for creating nodes!" papa: Good to hear, ngy. Keep us posted on how the massduinos perform, especially when you put larger demands on them. Then Problematic ...
In the next post, see ngy's followup report on the Massduino.
|
|
|
Post by papa on Mar 22, 2018 17:56:37 GMT
Another Possible Arduino Compatible for Nodesngy "I did notice a new board out, the Massduino by the same company as the Buono Uno boards. Have you tried any of them for additional cost savings?" papa: I have not tried the Massduino. The Massduino seems to have similar specs as the Buono Uno. Only differences I noticed: microprocessor, 12 bit vs 10 bit ADC resolution, & that Massduino shares 1kb EEPROM with flash memory. So the Massduino may be OK for this forum's projects.ngy: "my massduino boards came in, and they seem to operate just fine, based on my few basic sketches I uploaded to it. Looks like we have an even cheaper option for creating nodes!" papa: Good to hear, ngy. Keep us posted on how the massduinos perform, especially when you put larger demands on them. I'll post your findings in the Sources for Arduinos, sensors, etc. thread.
|
|
|
Post by papa on Mar 21, 2018 19:22:55 GMT
Addressing Concerns & Opportunities When RFM69 Transmissions Are Disabled
When RFM69 transmissions are disabled (so local node functions can still work), it is important to code what value the actuator (LED or relay) will hold afterwards: 1) OFF to avoid shocks, water overflows, etc. 2) ON so one could operate an attached appliance with its own switch. 3) Remain as it was before transmission was disabled.
Added to the node sketch's configuration lines:
#define AutoRadio // Disables & re-enables RFM69 radio sends, acc to transmission success. Allows node local functions to always work.
bool ACT1default = 0 ; // Default state of actuator (LED or Relay?) at start up & PERHAPS when RFM69 transmission is disabled. 0 = OFF, 1 = ON
bool ACT1Steady = 0 ; // When RFM69 transmission is disabled, 1 means ACT1State retains its current value, 0 means ACT1State = ACT1default ---------------------------------- In the setup() function, now: #ifdef ACTOR // Papa added pinMode(ACT1, OUTPUT); // set actuator 1 ACT1State = ACT1default; // Default value (0 or 1) is set above in configuration lines. digitalWrite(ACT1, ACT1State); // set status of ACT1 output. #endif // ifdef ACTOR -------------------------------- In the txRadio() function: #ifdef AutoRadio tx = false; // flag to disable transmitting, papa added Serial.println("Disabling transmission") ; // ?? leave ACT1State as is OR set to ACT1default ?? if ( ! ACT1Steady) { ACT1State = ACT1default; // Default value (0 or 1) is set above in configuration lines. digitalWrite(ACT1, ACT1State); // set status of ACT1 output. } // end of if ( ! ACT1Steady) #endif // end of ifdef AutoRadio } // end of if (retx)
|
|
|
Post by papa on Mar 21, 2018 0:54:48 GMT
OK, brump, I believe I understand the cases you described for possible relationships between local functions & RFM69 transmissions (working or failing). Now to think about whether to code for those cases & if yes, how ...
Case 1 sounds like my concern about water continuing to run to my garden bed if OpenHAB turned it on, but RFM69 transmissions were off when OpenHAB commanded the water off. This case could be addressed as I did my irrigation automation: if RFM69 transmission is failing, set the relay actuator to OFF.
Case 2 sounds like the opposite of Case 1. To address: if RFM69 transmission is failing, set the relay actuator to ON.
I believe Cases 1 & 2 can be addressed by small code additions, esp in the txRadio() function & in the initial configuration variables.
I believe Cases 3 & 4 are the same. They can be partly addressed by my code to disable RFM69 transmissions so local node functions can still work. Another initial configuration variable can flag whether output states remain steady when RFM69 transmission is disabled or be handled like Cases 1 or 2. A bonus of my code is that it re-establishes RFM69 transmissions if that becomes possible.
Assuming the code above for disabling & re-enabling RFM69 transmissions, the next post gives code additions to address these cases. Another bonus is that in a configuration line, we can set a default, startup value for the actuator.
I have added the code additions to the node choices sketch & used it to create a DHT Node which successfully controls a solid state relay according to the needs of the above cases.
In another thread, I will post the latest node choices sketch when I have the time & energy to document it.
|
|
|
Post by papa on Mar 20, 2018 17:40:06 GMT
brump: "Thinking about ... creating the node basic configuration for control of outputs in case of radio communications lost."
papa: brump, your thoughts offer a practical, cautious approach to what happens with node output states when radio transmission fails. Especially in bright blue text above, I added some notes & tweaks to your cases. Please check my additions to see if they are correct. (PS we might apply different cases to different node states, depending on what is best for each node state.)
brump: "I am struggling to write without the assistance of translators, so if there are grammatical errors, please [do not?] despise me."
papa: Your struggle is quite understandable & forgivable. Anytime you are away from translators, in a thread or in a personal message, you could write in your native language & I could put your words through Google Translate.
|
|