My home automation project incl dimmers

[brump]

Oct 30, 2017 13:25:29 GMT papa said:

Thanks for more specifics about your "generic node." Looks like you have a neatly done, useful product which packs many functions into a compact space. More questions: Will an ATMega processor be mounted on the board to host the programming or will this board be connected to an Arduino compatible (that is, is the board actually a "shield?") If it will connect to an Arduino compatible, how will it connect?

On the board I use an ATMega 328. The code loading will be via external rs232-usb converter. Another option would be to compile the moteino bootloader and write the codes via OTA.

[papa]

Good to hear from you, brump. Congratulations on having completed boards heading your way.

In this post, we said ... brump: "What do you think of having the node's code store the state in the processor's EEPROM memory?"  papa: "That may be useful for blackouts & power outages as you described. For example, if a power outage interrupted a period of irrigation, one would want the system to resume watering & complete the irrigation. ..."

papa: I had forgotten that conversation, but it planted the idea of using the EEPROM memory to hold key data that could be restored after a power outage.  I just finished a sketch to control cooking with a heating element which is documented in this thread.  This post explains how I used EEPROM memory & why.

[brump]

Thank you, Papa!

I saw your scketch, the idea is exactly that.

We only need to store the information received from openhab or trigger a local input in eeprom.
We also need to create a routine at startup to check the last value recorded in eeprom and execute the command and consequently openhab will be informed through an existing routine.

For the node I have developed, it will be necessary to create a function to read a potentiometer using the internal A / D converter, and convert the value to the TRIACS control using the dimmer function. This value will be converted into percent and sent to openhab to update the status. If the openhab sends a drive command the value read by the drive will have to be ignored, with the openhab command having priority.

What do you think?

[papa]

brump: "create a function to read a potentiometer using the internal A / D converter, and convert the value to the TRIACS control using the dimmer function"

papa: #define potPin A0 // A0 analog input from potentiometer
   // ?? something like a line in the Cooking Controller sketch ??
potRead = map(analogRead(potPin), 0, 1017, y, z) ; // function call maps range of values.
   // y & z are bottom & top limits for final results needed by the potentiometer reading function

    brump: "This value will be converted into percent and sent to openhab to update the status"
papa: If the mapped value sent to the dimmer function is not a percentage, the Arduino map function could convert it to be so.

    brump: "If the openhab sends a drive command the value read by the drive will have to be ignored, with the openhab command having priority."
        papa: Say more. I'm not sure what you mean.

[brump]

Dec 16, 2017 2:11:03 GMT papa said:

    brump: "If the openhab sends a drive command the value read by the drive will have to be ignored, with the openhab command having priority."
        papa: Say more. I'm not sure what you mean.

I'll explain better.

Use the on / off function to switch on a lamp, for example.

We have two situations:

1 - We send a command through openhab to turn on the lamp.
1a - The local switch (on the wall) is in the off position. Whereas the switch is on / off position.

1b - Arduino understands that the switch is already in the off position and keeps the output off. Upon receiving the command of openhab it discards the reading of the switch and assumes the last command sent by openhab.

2- The last command sent from openhab is ON.
2a - The switch is turned to the ON position. Nothing will happen.
2b- The swtich switches to the OFF position. The arduino will turn off the Output and send the information to openhab saying that the output has been turned off, causing openhab to update its status.

I know the current code already does this for some functions, (eg switch release).

My idea is to cover all functions of triggering or measuring potentiometers, etc.

[papa]

brump, just above: "I'll explain better ..."

brump, earlier: "For the node I have developed, it will be necessary to create a function to read a potentiometer using the internal A / D converter, and convert the value to the TRIACS control using the dimmer function. This value will be converted into percent and sent to openhab to update the status. If the openhab sends a drive command the value read by the drive will have to be ignored, with the openhab command having priority. What do you think?"

OK, I believe I understand. We want local control (for example, the push button on a full DHT node) to work (& update status in an OpenHAB UI), but a command from OpenHAB takes priority. For example, one could turn a light on & off with a local switch connected to WiFi/OpenHAB & OpenHAB UI would be updated. However, if OpenHAB sent a command (opposite to the switch's state) to the switch, the OpenHAB command would take priority.

greginkansas showed me the following double mqtt binding item that wonderfully achieves the above approach with a DHT node with an AC controlling relay:

    //item for an RFM69 node
Switch Act_Node05 { mqtt="<[mosquitto:home/rfm_gw/nb/node05/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node05/dev16:command:*:default]" }

    //sitemap
Switch item=Act_Node05 label="BaseFR05"

The above item & sitemap entry create a virtual switch on an OpenHAB UI. In the item, the first mqtt binding reads & updates device 16 (whether the relay is turned on or off. If the node's push button changes device 16's state, the first binding with read it. The second mqtt binding sends DHT Node 5's device 16 the ON or OFF command generated by the virtual switch which will over ride a state generated by the push button.

     // similar item for ESP8266 node
Switch Act_Node05 { mqtt="<[mosquitto:home/esp_gw/nb/node05/dev16:state:default::]", mqtt=">[mosquitto:home/esp_gw/sb/node05/dev16:command:*:default]" }

[brump]

Dec 23, 2017 2:43:26 GMT papa said:

OK, I believe I understand. We want local control (for example, the push button on a full DHT node) to work (& update status in an OpenHAB UI), but a command from OpenHAB takes priority. For example, one could turn a light on & off with a local switch connected to WiFi/OpenHAB & OpenHAB UI would be updated. However, if OpenHAB sent a command (opposite to the switch's state) to the switch, the OpenHAB command would take priority.

greginkansas showed me the following double mqtt binding item that wonderfully achieves the above approach with a DHT node with an AC controlling relay:

    //item for an RFM69 node
Switch Act_Node05 { mqtt="<[mosquitto:home/rfm_gw/nb/node05/dev16:state:default::]", mqtt=">[mosquitto:home/rfm_gw/sb/node05/dev16:command:*:default]" }

    //sitemap
Switch item=Act_Node05 label="BaseFR05"

The above item & sitemap entry create a virtual switch on an OpenHAB UI. In the item, the first mqtt binding reads & updates device 16 (whether the relay is turned on or off. If the node's push button changes device 16's state, the first binding with read it. The second mqtt binding sends DHT Node 5's device 16 the ON or OFF command generated by the virtual switch which will over ride a state generated by the push button.

     // similar item for ESP8266 node
Switch Act_Node05 { mqtt="<[mosquitto:home/esp_gw/nb/node05/dev16:state:default::]", mqtt=">[mosquitto:home/esp_gw/sb/node05/dev16:command:*:default]" }

Thanks Papa.

I'm changing the codes.
I'll post it here soon.
Could you review it?

[papa]

brump: "Thanks Papa. I'm changing the codes. I'll post it here soon. Could you review it?

papa: You're welcome.                          I look forward to looking over your code updates.

I just finished installing my RFM69-connected Cooking Controller in the project box & will start documenting it.

[brump]

Hello folks,

I was a bit busy with the birth of my daughter.
But the project continues...

I've been working on the code "computourist_node_v2.2MgH_choices_pub".
My code: computourist_node_v2.2MgI_choices_pub.ino (92.65 KB)


I inserted some necessary functions for the board that I developed.

POTDIM - Reading of a local potentiometer to control the output DIM1 (dimmer 1) and later actuation in openhab. Function responsible for controlling the intensity of a lamp. 0-100%

POTCF - Reading of a local potentiometer to control the output DIM2 (dimmer 2) and later actuation in openhab. Function responsible for controlling the speed of a ceiling fan. 0-100%

For reading the potentiometers using the Arduino A / D converter I chose to use the library <ResponsiveAnalogRead.h>.
ResponsiveAnalogRead is an Arduino library for eliminating noise in analogRead inputs without decreasing responsiveness. github.com/dxinteractive/ResponsiveAnalogRead

DIM1 - Function responsible for controlling a dimmable triac. A sub function is implicit in the code: Zerocross function: Detects the passage from zero in an AC phase.
Questions: search wiki.
For this function you will need to download the library at: github.com/circuitar/Dimmer

DIM2 - Function responsible for controlling a dimmable triac.
A sub function is implicit in the code: Zerocross function: Detects the passage from zero in an AC phase.
Questions: search wiki.

The zero cross function uses the internal interrupt in the processor. Originally the dimmer library uses interrupt 0 which is present on the D2 pin of the Arduino. This pin is used by RFM69HW.

Note: In dimmer.h you will need to make the following change
(red color):
Line 33: #define DIMMER_ZERO_CROSS_PIN 2
Line 33: #define DIMMER_ZERO_CROSS_PIN 3

Line 34: #define DIMMER_ZERO_CROSS_INTERRUPT 0
Line 34: #define DIMMER_ZERO_CROSS_INTERRUPT 1

CURSEN - AC current reading using the ACS712 sensor.
Library ACS712.h available at: github.com/rkoptev/ACS712-arduino/

SWT1, 2, 3, 4 - Switch to control relays.
In order to not change the code written by papa I implemented the devices 73, 74, 75, 76 as gateways in the gateways.
gateway 2.5: RFM_MQTT_GW_25.ino (15.73 KB)

RELAY 1, 2, 3, 4 - Relays used to drive external loads.

[papa]

Wow, brump, you & Joshua are adding many new features to the code. ( I need to think about how to merge everything.)

Nice work on adding to the Gateway Code to use previously unused device numbers in the 70's.

Nice summary as well.

[brump]

Hi Folks,

If we use this function POTDIM or POTCF to local control of a dimmer and remote control simultaneous, it´s necessary disable these functions on retransmition function.

        Find these lines after "/* PERIODIC TRANSMISSION */:  (2783-2789 ??)

#ifdef POTDIM // Brump added.
            send69 = true;
#endif // ifdef POTDIM

#ifdef POTCF // Brump added.
            send70 = true;
#endif // ifdef POTCF

        ^^  Comment all or remove!

[papa]

brump: "If we use this function potdim or potcf to local control of a dimmer and remote control simultaneous, it´s necessary disable this functions on retransmition function."

papa: brump, please say more about this to help us understand what you mean.

[brump]

Feb 21, 2018 19:58:01 GMT papa said:

brump: "If we use this function potdim or potcf to local control of a dimmer and remote control simultaneous, it´s necessary disable this functions on retransmition function."

papa: brump, please say more about this to help us understand what you mean.

If the POTDIR or POTCF functions are enabled for periodic retransmission, it will not be possible to control the output DIM1 or DIM2, as the information will periodically update the slider state in openhab.
Making the position you selected in openhab is lost, assuming the read state of the potentiometer.

[brump]

My PCB's have arrived.
Now another eternity ... Wait for the components to arrive.
I started the assembly with some that I had at home.

         Bottom                     Top

 
papa: Congrats, brump, on the arrival. Patience to wait for the pieces still to come.

[brump]

Mar 31, 2018 15:03:12 GMT papa said:

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 & Joshua, please test your code in the above sketch & report back your results. My thanks for your attention & contributions.

Hi Papa,

I will implement how the code will behave if communication with the gateway is lost on my node.
At the moment it still does not work.

After compiling the code I visualized two errors:

line 2384 and line 2393 contains the function written as txradio ();, but the correct one is txRadio (); . Just adjust and everything will work perfectly.


#ifdef POTDIM
if (send69) {
mes.devID = 69;
mes.intVal = potDIMRead; // brump
send69 = false;
txradio (); 
}
#endif

#ifdef POTCF
if (send70) {
mes.devID = 70;
mes.intVal = potCFRead; // brump
send70 = false;
txradio ();
}
#endif

---

Note: If you use the dimmer library, do not forget to update the interrupt pin.

In dimmer.h

lines 35, 36
#define DIMMER_ZERO_CROSS_PIN 3
#define DIMMER_ZERO_CROSS_INTERRUPT 1

Originally it is written:
lines 35, 36
#define DIMMER_ZERO_CROSS_PIN 2
#define DIMMER_ZERO_CROSS_INTERRUPT 0

Pin 2 is used by radio RFM69HW

---

[papa]

        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.

[brump]

My Server, Gateway and Local Display Control.

I use one monitor I used one 10 "touchscreen monitor (Advantech) with robust aluminum frame.

I installed the:

- arduino one
- ethernet gateway
- hdmi to vga converter
- lvds driver with vga input
- lcd light controller
- elo touchscreen usb controller
- raspberry pi
- wifi AP for ethernet gateway
- Traco Power DC / DC converter (18-70 VDC in ; 5V 4A out1; 12V 500mA Out2).


 

[brump]

What did you think?

Papa: You do neat work, brump. I continue to look forward to hearing about your future projects.

[greginkansas]

Was using the
- hdmi to vga converter
- lvds driver with vga input
- lcd light controller
- elo touchscreen usb controller
cheaper than using a hdmi monitor? or did you do it that way for the size.

[brump]

Jun 29, 2019 12:56:13 GMT greginkansas said:

Was using the
- hdmi to vga converter
- lvds driver with vga input
- lcd light controller
- elo touchscreen usb controller
cheaper than using a hdmi monitor? or did you do it that way for the size.

I used reused equipment. So I didn't spend anything.



If I were to buy, I would use a monitor with hdmi directly.