>>21423127 I connect floor heating actuators (those thermal ones with melting wax inside). They are around 2 watts each.
I don't remember how much power the relays consumed - but I remember that my first attempt with a 5V/0,5A power supply failed with all 8 relays powered. Had to use a 1A type. Consider, that during winter the floor heating is switched on almost all the time, for several weeks. That's a lot of power, and next you might have a temperature problem in a closed box, that I want to use.
Now you need only the power for the internal LEDs that need to lit. Almost nothing. Maybe 10mA for all 6 MOSFET-relays?
I could use one more hint, please. Remember, that I activated input detection here: Link Now, how can I read the actual value of the input, not the switched value? Because currently, when I have a signal on - let's say - input 2 (which is P22 on the chip), the device switches output 2 to "active" and the state indicator "get" changes accordingly to "1". But if I switch the channel 2 now to "off" in the webpage (which is the same as setting the "set" value to "0"), the "set" and "get" value will both be set to "0", and I cannot detect the real value for input 2 (which is still "1") any longer. Maybe, the mentioned "get" value isn't the input value at all, but the value for the output state (?). But how to get the value for the input, then?
Is there a way to get that done?
I'm not sure if I understand?
- if you are using dInput, then you can use dInput_n to invert logic
- if you are using ToggleChannelOnToggle, then it should just work - it works with bistable switch, it will toggle target channel on switch toggle
- if you have just a touch button or a classic button, then you can use Button, with optional immediate button reaction flag
What are you exactly trying to do?
You could try using dInput along with change callback to simulate yourself ToggleChannelOnToggle behaviour but still read dInput value, but why...
>>21435820 Let's make an example: For heating, a "1" (thermo switch is on) on input X will set output to "1", valve will open, room is heating up. Thermo switch then changes to "0", accordingly valve will close.
Now for cooling purpose, I have to invert logic: When thermo switch is "0", cooling has to start. So I have to set the output to "1", using the "SET" variable. But now the "GET" variable will change to "1" as well. Room is cooling down, thermo switch changes to "1" - but nothing happens now, cooling will run eternally unless input changes to "0" again. But that only happens on manual interaction, like turning the knob on the thermo switch.
I've been reading your post for like 10x already at various times of the day and I am still not sure if I understand....
Would you be able to draw a schematic, what is exactly on your inputs and outputs, and how you want to script them?
If you want to give HIGH signal to show the temperature is too low, then you can use dInput with Relay on the same channel. It will set relay to HIGH as long as temperature is too low - this will be a very simple heating.
If you want to inverse logic, you can either change dInput to dInput_n or Relay to Relay_n.
Of course, temperature control is usually more tricky than that, and you may want to have some kind of deadtime, so maybe it would be better to have temperature as a variable (channel) and use change handlers or a loop in OBK script to enable/disable heating within a certain margin.
Or do you mean that you want to use a single channel for both cooling and heating?
PS: You can't use SET when you have dInput, because dInput will SET given channel to value that is read from pin. So it makes no sense to use SET at the same time. It creates a race condition when two methods of setting channel fight each other.
SET can be used where you have a Relay and want to set it externally, via HA, etc
Thank you for your patience and effort. I made a schematic picture. It shows the original setup, the one with the relay only, and the final one with relay and input. Don't get confused about "dInput_n" and "dInput", it's just that there is an optocoupler inbetween, who inverts logic on the input side...
It also shows the OBK configuration and what I see in ioBroker.
Basic Version: If the thermo switch is on, the actuator is activ. Simple.
Relais only: If you switch the button on the OBK page to ON, the GET variable is "1" and the relais will activate the actuator. Same, if you or a script does set the SET variable to "1" - this will also change the state of the button on the OBK page. (This doesn't work the other way round - the SET variable will always stay on the value that you or the script did set).
Relais with input: Same as above, just that the thermo switch can activate the actuator again. Working fine for heating: Thermo switch goes on in cold room, Input is activ, output activates actuator. Later, the thermo switch goes off, Input is inactive, output is inactive. Excellent.
For cooling, you would have to reconfigure the Input from "dInput_n" to "dInput", which is probably not possible via script (is it?). Otherwise you will get into this situation: Thermo switch is off, because room is hot. To activate cooling, a script has to activate the output when the cooling machine starts to run, which means that it has to change the "SET" variable to "1". After a while the room is cold, thermo switch will go on - but that doesn't change anything, as output is already on, so cooling will not stop.
With "TglChanOnTgl" I can get around somehow (of course) - but that's far from being perfect. When device restarts and has no information about the current signal on input, you have a 50:50 chance that you will end up with inverted logic.
I'm still having problems understanding what are you exactly trying to achieve. You have one thermo switch and you want to use it for both cooling and heating?
Can you give a list of separate sensors and outputs you have? Do you have one thermo switch - or two? Do you have a separate cooler and heater? Or by "cooling" you mean turn off the heater...
io2345 wrote:
For cooling, you would have to reconfigure the Input from "dInput_n" to "dInput", which is probably not possible via script (is it?).
(This doesn't work the other way round - the SET variable will always stay on the value that you or the script did set).
What do you mean? You can set any channel to either 0 or 1. No problem.
io2345 wrote:
Otherwise you will get into this situation: Thermo switch is off, because room is hot. To activate cooling, a script has to activate the output when the cooling machine starts to run, which means that it has to change the "SET" variable to "1". After a while the room is cold, thermo switch will go on - but that doesn't change anything, as output is already on, so cooling will not stop.
What kind of script sets "SET" variable? You mean OBK script or what?
If you do in OBK script:
again:
delay_s 1
// mode 1
if $CH6==0 then setChannel 5 !$CH4
// mode 2 - sample
if $CH6==1 then setChannel 5 $CH4
// mode 3 - always on
if $CH6==2 then setChannel 5 1
// mode 4 - always off
if $CH6==3 then setChannel 5 0
goto again
So many options, depending on what you want to do
io2345 wrote:
Still no idea how to transmit the input value via MQTT?
This is incorrect approach, please consider doing it totally other way around. Input just reads digital pin value, nothing else. It's not supposed to be sent via MQTT.
I still don't even know if you have separate cooler and heater or just a single heater or what, but if I were to implement it, I'd so something like:
- one channel to hold mode - Automatic, Force On, Force Off ?
- gui for mode change
- dInput for thermo switch to know if room is hold
- Relay to enable heater
- manually in script, in a loop, check if mode is automatic, then setChannel of relay to value from dInput (you can use ! if you want negation), else if mode is forced, then set forced state
I could also add a "timer" mode.
I would love to make such script for you, but I would need to know more exactly which inputs and outputs you have. Which requirements.
Please fill a list, and forget about "SET" variable:
1. Inputs:
- thermo switch (gives 1 when room is cold)
- ......
- ......
2. Ouputs
- heater (when enables, heats up the room)
- ......
- ......
3. Control requirements
- I want to be able to either run automatic heating, or force it off, or force it on via OBK main panel
- ......
- ......
>>21448054 Thank you for your fast response. To be honest, I didn't think about the vast possiblities that could be present - probably, because the situation on my side is the most simple setup that could be: There is just one thermo switch (the one for the room) on the input side and one valve (the one for the floor heating/cooling) on the output side of the relay. There is hot water running through the floor heating circle on cold days. And cold water is circling in the same circle, when the cooling equipment is running.
The status of the cooling equipment (on or off) is transmitted to a home automation software, which is ioBroker in my case.
Input (for the relay) is 0 when room is cold and 1 when hot. (I already said that the logic on the relais' input is inverted, due to the opto coupler that I have to use between thermo switch and relay input)
Output is always the valve. 0 when closed, 1 to open the floor heating/cooling circle.
Control requirements: Everything should work without human interaction - and that's the point: Currently (without relay, just the basic setup in the schematic, so we have only switch and valve), you have to open the valve manually in cooling condition by setting the thermo switch to maximum temperature, as the logic for the valve to open is inverted: valve now has to be open when room is hot (unlike for heating condition, when valve has to close when the room is hot).
We can use scripts in ioBroker or on the OBK-device, but probably ioBroker is better, because there is already the information about the status of the cooling device as well as the output status of the relay.
What I still didn't understand so far: Is it possible to change the OBK-configuration at runtime (and which command should that be - I didn't find anything promising in the command list)? Because it would be easiest to change the input configuration from dInput_n to dInput for cooling condition as it is exactly what's happening: Inverted logic on the input side when it comes to cooling condition. But this information (cooling yes or no) can only be provided by ioBroker, so the script to reconfigure OBK-Input has to be initiated there.
>>21448054 In case that the reconfiguration of the input has to be done on the OBK-device itself, and an OBK-script needs information about the status of the cooling device: Is it possible to use a virtual channel to store the information? The relais uses eight channels for hardware. If it is possible to add a ninth channel in software, where ioBroker could set a "1" as long as the cooling device is running, would that be of any help? We could have then a local OBK-script running on the device, that checks periodically (like once a minute) for this information on the ninth channel, and if the value changes, it inverts the input-values on the eight hardware channels.
@p.kaczmarek2 One source of the misunderstandings is probably, that I know too little about OBK and you know too much So if you try to explain something to me, it might be similar like telling a stone age man how ETFs work...
For me, a "channel" in OBK was a set of input and output. But it turned out, that a channel isn't necessarily that. It also can be only input or only output.
Until now, I had configured the eight inputs on the same channel as the outputs. Now, I configured them to channels 9-16 and also introduced an additional channel #20 to display the status of the cooling device (this channel is set by a ioBroker-script to "1" when cooling is running) with the role "Rel" - just to be displayed on the devices page.
So now I have separate variables for input and output in ioBroker and could do everything from there with the help of some scripts.
But as you already suggested to create some script for OBK, it might be better in terms of system stability (home automation software or other infrastructure could fail) to script behaviour in OBK itself. Could you do that?:
If channel 20 has a value of "0" (which is the default): Map input channel # 9 to relais channel 1, input 10 to output 2, input 11 to output 3 and so on, until all eight input/output-combinations are set. When dInput_n on input-channels is "1", let output be "1"
If channel 20 has a value of "1": Invert output logic: When dInput_n is "1", let output be "0"
It is sufficient to check for changes on status-channel 20 only once a minute. System behaviour of floor heating is very slow anyway.
as you already suggested to create some script for OBK, it might be better in terms of system stability (home automation software or other infrastructure could fail) to script behaviour in OBK itself. Could you do that?
@p.kaczmarek2 Please be so kind and let me know, if you will try to provide an approriate script or not. No problem, if you don't want to, or have no spare time. I will try to find a different solution, then. But at least I wouldn't wait in vain.
If channel 20 has a value of "0" (which is the default): Map input channel # 9 to relais channel 1, input 10 to output 2, input 11 to output 3 and so on, until all eight input/output-combinations are set. When dInput_n on input-channels is "1", let output be "1"
If channel 20 has a value of "1": Invert output logic: When dInput_n is "1", let output be "0"
Then you can do a loop with conditionals, the simplest approach would be:
again:
if $CH20==0 then SetPinChannel 9 1
if $CH20==0 then SetPinChannel 10 2
if $CH20==1 then SetPinChannel 9 11
if $CH20==1 then SetPinChannel 10 12
delay_s 1
goto again
adjust pin indexes accordingly to your requirements. You can also change pin roles.
again:
if $CH20==0 then SetChannel 1 $CH9
if $CH20==0 then SetChannel 2 $CH10
// invert value if 1, ! is negation
if $CH20==1 then SetChannel 1 !$CH9
if $CH20==1 then SetChannel 2 !$CH10
delay_s 1
goto again
again:
if $CH20==0 then SetChannel 1 $CH9
if $CH20==0 then SetChannel 2 $CH10
if $CH20==0 then SetChannel 3 $CH11
if $CH20==0 then SetChannel 4 $CH12
if $CH20==0 then SetChannel 5 $CH13
if $CH20==0 then SetChannel 6 $CH14
if $CH20==0 then SetChannel 7 $CH15
if $CH20==0 then SetChannel 8 $CH16
// invert value if 1, ! is negation
if $CH20==1 then SetChannel 1 !$CH9
if $CH20==1 then SetChannel 2 !$CH10
if $CH20==1 then SetChannel 3 !$CH11
if $CH20==1 then SetChannel 4 !$CH12
if $CH20==1 then SetChannel 5 !$CH13
if $CH20==1 then SetChannel 6 !$CH14
if $CH20==1 then SetChannel 7 !$CH15
if $CH20==1 then SetChannel 8 !$CH16
delay_s 20
goto again
As currently this model is hard to find, I decided to try a different one, which is CBU based as well
Link: Link to Aliexpress If it is technically more or less the same than this board, I will just add a few lines. If it turns out to be something different, I will open another thread. Item should arrive by end of next week.
Device is here. I opened a new thread for this model: Link
I see, that's certainly an interesting setup. Did you document it with a final schematic? Also, that board on top, is it a custom-made board or can it be bought somewhere?
>>21540490 All documentation is in this thread. As this board version has an MCU that I don't even use, it would be better to use the board mentioned in #112 and here: Link The optocoupler is a cheap version that can be found in various Ali-Shops. Mine is from here: Link . The advantage is, that you can easily cut one until four elements on the sides, if space is a matter, so make - let's say - a five-channel version out of the 8-channel board.
The discussion revolves around the LLXLJY 8-channel smart Tuya switch and its compatibility with OpenBK7231T (OBK) firmware. Users share experiences regarding the device's firmware, specifically the BK7231N and BK7231M chipsets, and the challenges faced during firmware backup and flashing. The device is identified as a TuyaMCU, and users discuss methods for capturing packets and controlling the relays through the Tuya app and OBK. Various functionalities, such as relay toggling, interlocking, and remote control pairing, are explored. Users also address issues with initial state settings and the need for proper configuration to ensure reliable operation. The conversation includes technical details about command structures, baud rates, and the importance of understanding device data points (dpIDs) for effective control. Summary generated by the language model.