Link Input pin to an Output pin

[nielsonm236]

sjorsBe requested the following:
Would like to map a change on and input pin to cause action on an output pin. For example:
Using one module configured with 8 inputs and 8 outputs
Changing input 1 should activate output 1
Changing input 2 should activate output 2
Etc.
In this way the module can be used with standard switches and with smarthome devices

My initial comments:
Seems I discussed this with another user at some time, but I can't find that discussion in Issues. Might have been by email or in Youtube comments. At the time I think it was decided this functionality should be performed at a higher level, perhaps in HomeAssistant or similar control software. Since this is coming up again I'm willing to reconsider, and now we have an Issue to discuss and record conclusions.
I recall the original request was thought to be a bit complicated as a GUI was required to map the selected input pin to an output pin. But this could be simplified greatly if it is ALWAYS input1 maps to output1, input2 maps to output2, etc. If that is the assumption then an additional pin Type (perhaps "Mapped"?) could be defined to tell the firmware that the pin is an input and it is mapped to a predetermined output.
The underlying complications:

• "Mapped" would only be allowed on pins 1 to 8
• The corresponding pin must already be defined as an Output
• If the corresponding pin is defined as Input, Disabled, or is already used as a special function (I2C or Temp Sensor), then selecting "Mapped" will cause the pin to be forced back to Disabled. The user will need to be smart enough to realize that "Mapped" is disallowed on the pin as providing online feedback would be complicated. At least I think it would be complicated.
• The user would first have to define the Output pin as Output, SAVE the change, then define the Input pin as "Mapped".

I'm not sure what complications will be encountered. As it stands the Input change will cause a fairly fast Output change (milliseconds ... but could be hundreds of milliseconds depending on what else is happening). That time probably cannot be well defined.

This would probably be a feature for all release types (non-updatable AND updatable). It will depend on how much code is involved.

So, another idea on the queue.

Mike

[sjorsBe]

All,

it would be great to have some kind of solution like that.
It brings the possibility to automate e.g. standard wall switches to be used with a netmodule and relais .
it brings the possibility to be able to switch locally AND as smart device….

i spent some time in the Sonoff world, where people liked to make that happen with sonoff basics. And ended up with extremely nasty and risky solutions. This could be a clean and stable solution…..
Please give your thoughts

kr
Sjors

[yozik04]

With standard wall switches there will be a more complex solution.

Let's assume if we map input to output.

1. Input is wired to the switch and circuit is OPEN, Output is OFF
2. Ok, we toggle the switch state becomes the following
3. Input circuit is CLOSED, Output is ON, all fine.
4. Now we toggle input through the network.
5. Input circuit is still CLOSED, but Output should be OFF. Hmmm. Mismatch..
6. Let's toggle switch now.
7. Input circuit is now OPEN, but Output should be ON.... Not the way it was in the beginning.
8. Let's toggle again through the network
9. Input circuit is OPEN, Output is Off, all has returned to the initial state.

So the NetModule would need to hold a virtual switch (network) state somewhere and it should survive reboot. Otherwise you would have some random lights ON after every blackout. I am sure you will not like that.

[yozik04]

To work with switches

1. Output needs to be in initial state (defined in UI) after every reboot. Regardless of Input.
2. Input state change should toggle output. Regardless of if it was OPEN or CLOSED.
3. Network command should set output state to what was sent in the packet.

[jmcvieira1]

Hello
If we use a push button stile switch the input circuit is closed for a moment,(doorbell button) but the network module needed to toggle de output on or off at each button press.

[sjorsBe]

cant we use the "invert" setting of the module to tackle the problem?
whenever the network toggles the invert setting, it looks like the entire issue is solved Or am i not overseeing the whole issue?. Add payload "invert" to mqtt including the client software behind it.

kr

Sjors

[yozik04]

Invert is a bit in memory stored on chip. You do not want to toggle that. Chip has a finite amount of writes.

[sjorsBe]

It should be possible to load the invert state to ram while booting the netmodule (max 16 bits) and redirect the status invert requests to that position in ram.
Whenever the netmodule boots it looks at the bootstate setting which is a separate setting. And updates the ram invert setting to functional off depending the linked input.

So
If switch is in "on" position while booting ...
Netmodule looks at the "stored on chip" invert setting belonging go the corresponding output.
If that setting tells that the output must be "on" at boot time
The new to be created extra RAM invert setting is 0.
Result: switch and output are in sync.
If the "stored on chip" invert setting tells that the output must be "off" at boot time, the new to be created extra RAM invert setting is "1", meaning that the switch input
has to be inverted in order to obtain a functional "off".

During operation the netmodule can "switch" by changing the RAM invert status either by the module or by physical switch.

So just on the bootcycle it needs an extra check when an input output link is in place.

I hope i explain it so it is understandable :)
I think that should work .. and wont consume much ram and save the flash writecycles

[yozik04]

Question if we have enough RAM for that =) I understood we have some code space left but almost no RAM. @nielsonm236

[sjorsBe]

Its a lousy 2 bytes :)

[nielsonm236]

The two bytes I'm not so worried about (although we are working with the last 20 or so bytes of RAM ... and I still want to get some promised sensor work done for @jmcvieira1). Maintaining current functionality plus implementing this functionality is of greater concern. I need to think through what @sjorsBe said above.

By the way, the "Mapped" setting I described above is stored in EEPROM. So that cannot be changed frequently (as @yozik04 described there is limited writes to the EEPROM).

@sjorsBe Above you say "Netmodule looks at the flash setting." Which setting?
Above you say "If it is not set, it looks at the input setting ..." Which setting?
Just looking for clarity so I'm not misunderstanding.

I think we need a small boolean table to make sure this will always work through boot (or multiple boots).

[nielsonm236]

A concern with the suggestion that the Invert settings be loaded to RAM and operate from there. If power is lost (or glitched) the Invert settings in RAM will be lost, and it might be very confusing to the user to get things back in sync. That is why we store them in EEPROM (to survive a power glitch or reboot). So this needs some more thought.

Another thought: Since this function is directed at making an Input pin control an Output pin, when a pair of pins are "mapped" I could disable MQTT, Browser, and REST from changing the Output state. Only the Input pin could change the Output state.

What is the use case where pins are mapped, but we also want MQTT/Browser/REST to change the Output state? I suppose it could be the case that there is some remote light that was turned on with a remote physical switch (say out at a storage shed), then later you want to turn the light off from the house. If that is the case I like the @jmcvieira1 suggestion that the remote physical switch should have the properties of a "push button". It creates a pulse that toggles the state of the Output. Then the MQTT/Browser/REST command can see the Output state and can toggle it again if needed later. Any switch can generate a pulse with a minor bit of hardware added. And having said that ... I could perhaps write code that would detect a switch edge rather than the switch state, and use that edge as the push-button detect. Of course this requires software debounce. That way any time the switch position changes I can flip the Output state. But that switch now has the properties of a single-pole-double-throw switch ... it doesn't have an "ON" state, only a "change it from what it is now" function. Does that work?

[sjorsBe]

Hi Mike,

You asked about a use case.
Im looking for a possibility to be able to use the netmodule functionality on my phone AND be able to keep using my wall switches. The extra requirement is that the wall switches keep on working even when there is no network connection available on the netmodule and the network module fall back to "stand alone" mode.
The beauty of the netmodule is that it could support max 8 outputs ( like solid state relais or other switchable devices )
With 8 different inputs EVEN WHEN THERE IS NO NETWORK AVAILABLE!!!. So even with an IT problem in the house people can still use the devices.
The remote control option (trough tablet or smartphone ) is an extra convenience instead of a necessity.
Its therefore easily used as a low cost domotica solution for non technical elderly people.

[sjorsBe]

Hi Mike

So the module should keep on supporting the mqtt protocol to be connected to the smart actuators in the house.
The local switch option is a failsafe which can be easily explained to elderly people.

[nielsonm236]

I like the described use case - good idea. And I understand the elderly people issue ... that's my resting state.

Does my suggestion of flipping the output state if I see an edge on the input work? If the physical switch is moved the output state is simply flipped. So, it could be a toggle switch or a push-button - either will function the same way.