On 18-May-21 11:02 am, Phil Allison wrote:
> Sylvia Else wrote:
> ========================
>>>
>> The 433MHz RF solution has the issue that if you cannot see the light
>> that's being controlled, you cannot tell whether the control instruction
>> was obeyed in any given instance ...
>>
>>
> ** Contradicts TW's actual question.
>
> Go read it again.
>

That's not how I read it.

WiFi is after all an RF solution. My take on TW's requirement was that
it was not an Internet dependent solution. A WiFi network with no
Internet access is just a particular way of using RF to link components.

Sylvia.

On Tuesday, May 18, 2021 at 12:10:22 PM UTC+10, Sylvia Else wrote:
> On 18-May-21 11:02 am, Phil Allison wrote:
> > Sylvia Else wrote:
> > ========================
> >>>
> >> The 433MHz RF solution has the issue that if you cannot see the light
> >> that's being controlled, you cannot tell whether the control instruction
> >> was obeyed in any given instance ...
> >>
> >>
> > ** Contradicts TW's actual question.
> >
> > Go read it again.
> >
> That's not how I read it.

** FFS there is NO issue with seeing the light go an and off.

Read what is actually fucking says !!!

On 17/05/2021 7:28 pm, Sylvia Else wrote:
> On 16-May-21 7:23 am, Trevor Wilson wrote:
>> Well, not quite home automation, but SWMBO has decreed that I do
>> something about the garage lighting. Here's what I think might make
>> her happy:
>>
>> * Remote control of lighting outside the garage, which can be switched
>> on at the back door of the house. I need about 20 Metres of range. I
>> don't want to run new wiring, so remote control is the go. For this
>> purpose, I want to avoid a wi-fi based system, but a supplementary
>> wi-fi based system would be acceptable.
>>
>> * Remote control of the stair lighting for the first floor. Running
>> new wiring for this application would be extremely intrusive and very
>> expensive, so remote control would also be the best way to go. Again,
>> no wi-fi, but supplementary wi-fi would be a good thing.
>>
>> * Since I'm doing the above, I thought I might think about running all
>> the house lighting from a similar system.
>>
>> Turks were useless.
>>
>> TIA for any tips.
>>
>
>
>
> Not sure what you mean by "no wi-fi, but supplementary wi-fi would be a
> good thing"
>
> Certainly, one doesn't want a device phoning-home to some unknown web
> site, much less relying on the Internet to work at all.
>
> After some thought, I realised that simple RF solutions have the
> limitation that unless you can see whether changing the switch position
> had any effect, there needs to be two-way communication between the
> remote controller and the local switch, and WiFi makes sense for that.
>
> If I had to implement this from scratch, then on the controller side I'd
> probably go with a microcontroller (something out of the PIC24
> families), a serial-port Wifi module, and a latching relay driven by an
> H-bridge chip. I think all that could be driven via a capacitive dropper
> (charge a capacitor to operate the relay coil).

Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
built in WiFi.

> The quiescent power drain is dominated by the Wifi module. At least some
> such modules can act as an access point.
>
> On the switch side, omit the H-bridge chip and relay. One could design a
> circuit board for both parts, and just not fully populate the switch side.
>
> Sylvia.
>

On 17/05/2021 7:34 pm, Trevor Wilson wrote:
> On 17/05/2021 7:28 pm, Sylvia Else wrote:
>> On 16-May-21 7:23 am, Trevor Wilson wrote:
>>> Well, not quite home automation, but SWMBO has decreed that I do
>>> something about the garage lighting. Here's what I think might make
>>> her happy:
>>>
>>> * Remote control of lighting outside the garage, which can be
>>> switched on at the back door of the house. I need about 20 Metres of
>>> range. I don't want to run new wiring, so remote control is the go.
>>> For this purpose, I want to avoid a wi-fi based system, but a
>>> supplementary wi-fi based system would be acceptable.
>>>
>>> * Remote control of the stair lighting for the first floor. Running
>>> new wiring for this application would be extremely intrusive and very
>>> expensive, so remote control would also be the best way to go. Again,
>>> no wi-fi, but supplementary wi-fi would be a good thing.
>>>
>>> * Since I'm doing the above, I thought I might think about running
>>> all the house lighting from a similar system.
>>>
>>> Turks were useless.
>>>
>>> TIA for any tips.
>>>
>>
>>
>>
>> Not sure what you mean by "no wi-fi, but supplementary wi-fi would be
>> a good thing"
>
> **Sorry, I didn't explain it very well. Here goes:
>
> I want a primarily RF system. I do not want a system that relies only on
> a cell 'phone/wi-fi system.
>
>>
>> Certainly, one doesn't want a device phoning-home to some unknown web
>> site, much less relying on the Internet to work at all.
>>
>> After some thought, I realised that simple RF solutions have the
>> limitation that unless you can see whether changing the switch
>> position had any effect, there needs to be two-way communication
>> between the remote controller and the local switch, and WiFi makes
>> sense for that.
>
> **Correct.
>
>>
>> If I had to implement this from scratch, then on the controller side
>> I'd probably go with a microcontroller (something out of the PIC24
>> families), a serial-port Wifi module, and a latching relay driven by
>> an H-bridge chip. I think all that could be driven via a capacitive
>> dropper (charge a capacitor to operate the relay coil).
>>
>> The quiescent power drain is dominated by the Wifi module. At least
>> some such modules can act as an access point.
>>
>> On the switch side, omit the H-bridge chip and relay. One could design
>> a circuit board for both parts, and just not fully populate the switch
>> side.
>
> **I am confident that there is an off-the-shelf solution available.
>
>
https://www.banggood.com/Geekcreit-433MHz-DC-12V-10A-Relay-1CH-Channel-Wireless-RF-Remote-Control-Switch-Transmitter-With-Receiver-p-1040721.html?cur_warehouse=USA&rmmds=search

https://www.banggood.com/433Mhz-DC12V-1CH-Wireless-Remote-Control-Switch-Relay-Receiver-Module-+-2-RF-Transmitter-p-1326823.html?cur_warehouse=USA&rmmds=search

Both are rated 240v at 10A although I wouldn't actually try to push 10
amps through one.

On 18-May-21 4:28 pm, keithr0 wrote:
> On 17/05/2021 7:28 pm, Sylvia Else wrote:
>> On 16-May-21 7:23 am, Trevor Wilson wrote:
>>> Well, not quite home automation, but SWMBO has decreed that I do
>>> something about the garage lighting. Here's what I think might make
>>> her happy:
>>>
>>> * Remote control of lighting outside the garage, which can be
>>> switched on at the back door of the house. I need about 20 Metres of
>>> range. I don't want to run new wiring, so remote control is the go.
>>> For this purpose, I want to avoid a wi-fi based system, but a
>>> supplementary wi-fi based system would be acceptable.
>>>
>>> * Remote control of the stair lighting for the first floor. Running
>>> new wiring for this application would be extremely intrusive and very
>>> expensive, so remote control would also be the best way to go. Again,
>>> no wi-fi, but supplementary wi-fi would be a good thing.
>>>
>>> * Since I'm doing the above, I thought I might think about running
>>> all the house lighting from a similar system.
>>>
>>> Turks were useless.
>>>
>>> TIA for any tips.
>>>
>>
>>
>>
>> Not sure what you mean by "no wi-fi, but supplementary wi-fi would be
>> a good thing"
>>
>> Certainly, one doesn't want a device phoning-home to some unknown web
>> site, much less relying on the Internet to work at all.
>>
>> After some thought, I realised that simple RF solutions have the
>> limitation that unless you can see whether changing the switch
>> position had any effect, there needs to be two-way communication
>> between the remote controller and the local switch, and WiFi makes
>> sense for that.
>>
>> If I had to implement this from scratch, then on the controller side
>> I'd probably go with a microcontroller (something out of the PIC24
>> families), a serial-port Wifi module, and a latching relay driven by
>> an H-bridge chip. I think all that could be driven via a capacitive
>> dropper (charge a capacitor to operate the relay coil).
>
> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
> built in WiFi.

Mainly familiarity with programming a PIC24.

Sylvia.

On 18/05/2021 5:21 pm, Sylvia Else wrote:
> On 18-May-21 4:28 pm, keithr0 wrote:
>> On 17/05/2021 7:28 pm, Sylvia Else wrote:
>>> On 16-May-21 7:23 am, Trevor Wilson wrote:
>>>> Well, not quite home automation, but SWMBO has decreed that I do
>>>> something about the garage lighting. Here's what I think might make
>>>> her happy:
>>>>
>>>> * Remote control of lighting outside the garage, which can be
>>>> switched on at the back door of the house. I need about 20 Metres of
>>>> range. I don't want to run new wiring, so remote control is the go.
>>>> For this purpose, I want to avoid a wi-fi based system, but a
>>>> supplementary wi-fi based system would be acceptable.
>>>>
>>>> * Remote control of the stair lighting for the first floor. Running
>>>> new wiring for this application would be extremely intrusive and
>>>> very expensive, so remote control would also be the best way to go.
>>>> Again, no wi-fi, but supplementary wi-fi would be a good thing.
>>>>
>>>> * Since I'm doing the above, I thought I might think about running
>>>> all the house lighting from a similar system.
>>>>
>>>> Turks were useless.
>>>>
>>>> TIA for any tips.
>>>>
>>>
>>>
>>>
>>> Not sure what you mean by "no wi-fi, but supplementary wi-fi would be
>>> a good thing"
>>>
>>> Certainly, one doesn't want a device phoning-home to some unknown web
>>> site, much less relying on the Internet to work at all.
>>>
>>> After some thought, I realised that simple RF solutions have the
>>> limitation that unless you can see whether changing the switch
>>> position had any effect, there needs to be two-way communication
>>> between the remote controller and the local switch, and WiFi makes
>>> sense for that.
>>>
>>> If I had to implement this from scratch, then on the controller side
>>> I'd probably go with a microcontroller (something out of the PIC24
>>> families), a serial-port Wifi module, and a latching relay driven by
>>> an H-bridge chip. I think all that could be driven via a capacitive
>>> dropper (charge a capacitor to operate the relay coil).
>>
>> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
>> built in WiFi.
>
> Mainly familiarity with programming a PIC24.
>
> Sylvia.

if you program in C or C++ there would be little difference. I use one
of the Arduino IDEs to program it.

keithr0 <user@account.invalid> wrote:
> On 18/05/2021 5:21 pm, Sylvia Else wrote:
>> On 18-May-21 4:28 pm, keithr0 wrote:
>>>
>>> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
>>> built in WiFi.
>>
>> Mainly familiarity with programming a PIC24.
>
> if you program in C or C++ there would be little difference.

There'd be a lot of difference regarding the how the registers
behave, and the custom language extensions recognised by the
compiler.

> I use one of the Arduino IDEs to program it.

That's more the point rather than programming in C or C++. If you
already access everything via Arduino libraries then it might seem
easy to switch platforms. It's not the most efficient way to
program a microcontroller though.

--
__ __
#_ < |\| |< _#

On 18-May-21 4:28 pm, keithr0 wrote:
> On 17/05/2021 7:28 pm, Sylvia Else wrote:
>> On 16-May-21 7:23 am, Trevor Wilson wrote:
>>> Well, not quite home automation, but SWMBO has decreed that I do
>>> something about the garage lighting. Here's what I think might make
>>> her happy:
>>>
>>> * Remote control of lighting outside the garage, which can be
>>> switched on at the back door of the house. I need about 20 Metres of
>>> range. I don't want to run new wiring, so remote control is the go.
>>> For this purpose, I want to avoid a wi-fi based system, but a
>>> supplementary wi-fi based system would be acceptable.
>>>
>>> * Remote control of the stair lighting for the first floor. Running
>>> new wiring for this application would be extremely intrusive and very
>>> expensive, so remote control would also be the best way to go. Again,
>>> no wi-fi, but supplementary wi-fi would be a good thing.
>>>
>>> * Since I'm doing the above, I thought I might think about running
>>> all the house lighting from a similar system.
>>>
>>> Turks were useless.
>>>
>>> TIA for any tips.
>>>
>>
>>
>>
>> Not sure what you mean by "no wi-fi, but supplementary wi-fi would be
>> a good thing"
>>
>> Certainly, one doesn't want a device phoning-home to some unknown web
>> site, much less relying on the Internet to work at all.
>>
>> After some thought, I realised that simple RF solutions have the
>> limitation that unless you can see whether changing the switch
>> position had any effect, there needs to be two-way communication
>> between the remote controller and the local switch, and WiFi makes
>> sense for that.
>>
>> If I had to implement this from scratch, then on the controller side
>> I'd probably go with a microcontroller (something out of the PIC24
>> families), a serial-port Wifi module, and a latching relay driven by
>> an H-bridge chip. I think all that could be driven via a capacitive
>> dropper (charge a capacitor to operate the relay coil).
>
> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
> built in WiFi.
>
>> The quiescent power drain is dominated by the Wifi module. At least
>> some such modules can act as an access point.
>>
>> On the switch side, omit the H-bridge chip and relay. One could design
>> a circuit board for both parts, and just not fully populate the switch
>> side.
>>
>> Sylvia.
>>
>

Or one could get away from WiFi by using something like this to
implement a two way protocol, though then one has to do something about
security (if one cares that much in the case of lighting control). It
does have a lower quiescent power consumption.

https://au.rs-online.com/web/p/rf-modules/1225257/

Sylvia.

On 19/05/2021 8:43 am, Computer Nerd Kev wrote:
> keithr0 <user@account.invalid> wrote:
>> On 18/05/2021 5:21 pm, Sylvia Else wrote:
>>> On 18-May-21 4:28 pm, keithr0 wrote:
>>>>
>>>> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
>>>> built in WiFi.
>>>
>>> Mainly familiarity with programming a PIC24.
>>
>> if you program in C or C++ there would be little difference.
>
> There'd be a lot of difference regarding the how the registers
> behave, and the custom language extensions recognised by the
> compiler.

C is C, the only real difference comes with what capabilities a
processor has and I/O

>> I use one of the Arduino IDEs to program it.
>
> That's more the point rather than programming in C or C++. If you
> already access everything via Arduino libraries then it might seem
> easy to switch platforms. It's not the most efficient way to
> program a microcontroller though.
>
How so? Even in microcontrollers efficiency is not as important as it
used to be unless you are going to produce something in the millions.

On 19-May-21 3:58 pm, keithr0 wrote:

> C is C, the only real difference comes with what capabilities a
> processor has and I/O

It's exactly here that things go wrong. Having interposed third party
libraries just makes things harder to figure out when the MCU doesn't
behave as expected.

Sylvia.

keithr0 <user@account.invalid> wrote:
> On 19/05/2021 8:43 am, Computer Nerd Kev wrote:
>> keithr0 <user@account.invalid> wrote:
>>> On 18/05/2021 5:21 pm, Sylvia Else wrote:
>>>> On 18-May-21 4:28 pm, keithr0 wrote:
>>>>>
>>>>> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
>>>>> built in WiFi.
>>>>
>>>> Mainly familiarity with programming a PIC24.
>>>
>>> if you program in C or C++ there would be little difference.
>>
>> There'd be a lot of difference regarding the how the registers
>> behave, and the custom language extensions recognised by the
>> compiler.
>
> C is C, the only real difference comes with what capabilities a
> processor has and I/O

But you need to write different values to different registers
in order to control the I/O and special functions of different
microcontrollers. You may have a library that abstracts all that
for you, but in using that you limit the range and performance of
the hardware's functionality, while also making debugging more
difficult as Sylvia pointed out.

Compilers for many microcontrollers also tend to implement
extensions to the C standard, so C isn't always C either, if
you're used to taking advantage of those extensions.

>>> I use one of the Arduino IDEs to program it.
>>
>> That's more the point rather than programming in C or C++. If you
>> already access everything via Arduino libraries then it might seem
>> easy to switch platforms. It's not the most efficient way to
>> program a microcontroller though.
>>
> How so? Even in microcontrollers efficiency is not as important as it
> used to be unless you are going to produce something in the millions.

If your code accesses the device's registers directly for all
hardware functions, then you know roughly what timing delays will
happen. If you use other libraries, then you don't know for sure
what is going on in the background that might cause unexpected
behaviour. If you're only ever toggling a light on and off, then
that might not be a worry, but if you're actually pushing the
hardware then it becomes important.

--
__ __
#_ < |\| |< _#

On 20/05/2021 8:56 am, Computer Nerd Kev wrote:
> keithr0 <user@account.invalid> wrote:
>> On 19/05/2021 8:43 am, Computer Nerd Kev wrote:
>>> keithr0 <user@account.invalid> wrote:
>>>> On 18/05/2021 5:21 pm, Sylvia Else wrote:
>>>>> On 18-May-21 4:28 pm, keithr0 wrote:
>>>>>>
>>>>>> Why use a pic when the ESP32 has both a micro-controller (2 CPUs) and
>>>>>> built in WiFi.
>>>>>
>>>>> Mainly familiarity with programming a PIC24.
>>>>
>>>> if you program in C or C++ there would be little difference.
>>>
>>> There'd be a lot of difference regarding the how the registers
>>> behave, and the custom language extensions recognised by the
>>> compiler.
>>
>> C is C, the only real difference comes with what capabilities a
>> processor has and I/O
>
> But you need to write different values to different registers
> in order to control the I/O and special functions of different
> microcontrollers. You may have a library that abstracts all that
> for you, but in using that you limit the range and performance of
> the hardware's functionality, while also making debugging more
> difficult as Sylvia pointed out.

The libraries in the Arduino universe come in source form, if you do
have problems, you can delve right in, or modify them to meet your needs.

> Compilers for many microcontrollers also tend to implement
> extensions to the C standard, so C isn't always C either, if
> you're used to taking advantage of those extensions.

Most use GCC in some form, that's pretty universal.

>>>> I use one of the Arduino IDEs to program it.
>>>
>>> That's more the point rather than programming in C or C++. If you
>>> already access everything via Arduino libraries then it might seem
>>> easy to switch platforms. It's not the most efficient way to
>>> program a microcontroller though.
>>>
>> How so? Even in microcontrollers efficiency is not as important as it
>> used to be unless you are going to produce something in the millions.
>
> If your code accesses the device's registers directly for all
> hardware functions, then you know roughly what timing delays will
> happen. If you use other libraries, then you don't know for sure
> what is going on in the background that might cause unexpected
> behaviour. If you're only ever toggling a light on and off, then
> that might not be a worry, but if you're actually pushing the
> hardware then it becomes important.
>
If its that critical, and not many functions are (unless you are
controlling some critical industrial process) then you'd probably be
using assembler and the SDK for the particular processor. However, I'll
bet that 99% of applications don't need that, certainly Trevors doesn't.

On 19/05/2021 4:03 pm, Sylvia Else wrote:
> On 19-May-21 3:58 pm, keithr0 wrote:
>
>> C is C, the only real difference comes with what capabilities a
>> processor has and I/O
>
> It's exactly here that things go wrong. Having interposed third party
> libraries just makes things harder to figure out when the MCU doesn't
> behave as expected.
>
> Sylvia.

Maybe, but I've never had any problems in that regard using a whole
bunch of different devices.