I can't find on google or on the forum how to make an esp8266 based gateway with a local relay connected report the state of the relay back to my controller(which is a vera, but that should't matter). Thanks for the help.
Hi,
nice projet. I am very interested in it.
But why you are using 5 V and not 3.3 V? The ATmea328 works with 3.3 V too and the NRF have to use 3.3 V.
The only restriction on 3.3 V is the clock limitation for the Atmega (8 MHz). But with no crystal it don't care.
For example you could use an HLK-PM03 instead of HLK-PM01 and remove the linear voltage regulator. So you get more space an everything have the same voltage level.
And another point is, it is recommended to use a capacitor (0.1 µF) to ground for each voltage pin (Vcc, Avcc, Aref).
@Samuel235 said in Homini AC Powered Relay (2) Module:
OMRON G3MB-202P
Okay I'm trying to help you with the fuse component.
I found a datasheet for the OMRON G3MB-202P. And there are enoght information to be known for fuse selection.
I try to calculate it here (and i will try it with my bad English ).
The most important information is the melting integral.
The Melting integral has A²s as unit. So this means the maximum current for a time can exists without damaging the device. For further information look at wikipedia.
So we need any further information about:
the protection which is present before (the typical circuit protection in private houses)
the melting integral from the device which we want to protect
the maximum voltage
the maximum switching current
the breaking capacity
Inrush current for the switched devices (we can't know)
Typical values for an automatic circuit breaker in private houses are:
from 25 to 100 A²s
230 V AC
16 A
So this protection isn't good enough for our relay. The relay have these values:
230 V AC
2 A maximum switching current
I²t value (melting integral): 4 A²s
the allowed inrush current over a small time is higher than the melting integral. It is a bit confusing i think, but if we calculate the protection for the given melting integral and it's fine. So we can define the parameters for the client (switching site of this application here)
The fuse have to be:
I²s value higher or equal than the I²s value from the existing protection
rating voltage over 230 V AC
rating current 2 A or lower (because 2 A is the maximum at 25 °C, for 40 °C it is about 1.6 A)
a maximum switching time of 1 second at 2 A or lower time with higher current but below 4A²s! To calculate use the switching time from the fuse datasheet an multiply it two times with the given current for this switching time.
And i think a fast blow fuse would be the best. There are SMD fuses with 10.1 x 3 mm and 250 V AC available.
If there is no fuse available with the values above, we could combine multiple fuses. A possible solution could be one bigger fuse for both relays and the ac/dc component. And a smaller fuse for the switching site of the relay and the HLK-PM01. But for this it is important that the circuit have only one input for the hot one (L) of 230 V and one output for each relay. In this case we could reduce the big connectors from 6 to 4. Like (L, N, Relay1, Relay2).
And the temperature fuse can work for all components too
So the protection for the primary site of the HLK-PM01 is a problem i think. Because the are no information available about the I²s value from HLK-PM01.
I hope you can understand my English and could follow my explanation?
The updates have been applied to Rev 2, below we have a list of everything that has been added/modified;
Modification footprint for 3 items to make it easier to mount (Slow blow fuse, Thermal Fuse and Voltage Regulator) when hand soldering.
Modification to nRF24L01+ Module to remove the short to ground on VCC line.
Added the additional silkscreen labeling that was missed off by accident.
This should be all that is needed for Rev 2 to be a successor to the Rev 1. We still have the issue with having to use pogo pins to program through the ISP connection, or to temporarily solder jumper wire into the 6 pin connection while uploading, then everything else can be programmed through the on-board FTDI connection.
Will get the gerber files generated ASAP and then get them sent off for testing production runs.
@C.r.a.z.y.
yeah.... those are VERY bouncy.
are you interrupt triggering or just using a state change?
post your code, let's make sure you have it de-bounced enough.
