Do you know how to use gpio command tool and how to command a mcp23017-pin? I will try to do so this evening or tomorrow.
No idea
http://wiringpi.com/the-gpio-utility/
Another thought - confident you are looking at the correct pin? Your [default_state=“HIGH”] experiment should have confirmed that.
You are the best! I have checked the wireing a thousand times but you let me have a look at it again. I connected A7 instead of A0. Now it workes and I just have loop which is a problem of the rule. This should be a problem which I can solve by myself.
Sorry for bothering you the last days with such a stupid mistake. I will write a summary this evening.
Thanks again an best regards
BrainPain
How did that default high/low appear to work, then? You configured more pins than you showed us, or all outputs adopt the same, or?
I use two MCP23017 and created the following thing:
Thing mcp23017:mcp23017:input1 "MCP23017 Input 1" [address=20,bus=1] {
//input-Pins
Type input_pin : input#A0
Type input_pin : input#A1
Type input_pin : input#A2
Type input_pin : input#A3
Type input_pin : input#A4
Type input_pin : input#A5
Type input_pin : input#A6
Type input_pin : input#A7
Type input_pin : input#B0
Type input_pin : input#B1
Type input_pin : input#B2
Type input_pin : input#B3
Type input_pin : input#B4
Type input_pin : input#B5
Type input_pin : input#B6
Type input_pin : input#B7
}
Thing mcp23017:mcp23017:output1 "MCP23017 Output 1" [address=24,bus=1] {
//output-Pins
Type output_pin : output#A0 [default_state="HIGH"]
Type output_pin : output#A1 [default_state="HIGH"]
Type output_pin : output#A2 [default_state="HIGH"]
Type output_pin : output#A3 [default_state="HIGH"]
Type output_pin : output#A4 [default_state="HIGH"]
Type output_pin : output#A5 [default_state="HIGH"]
Type output_pin : output#A6 [default_state="HIGH"]
Type output_pin : output#A7 [default_state="HIGH"]
Type output_pin : output#B0 [default_state="HIGH"]
Type output_pin : output#B1 [default_state="HIGH"]
Type output_pin : output#B2 [default_state="HIGH"]
Type output_pin : output#B3 [default_state="HIGH"]
Type output_pin : output#B4 [default_state="HIGH"]
Type output_pin : output#B5 [default_state="HIGH"]
Type output_pin : output#B6 [default_state="HIGH"]
Type output_pin : output#B7 [default_state="HIGH"]
}
But I just use B0 of the input-chip as an input and A0 of the output-chip as an output:
Switch
living_room_led_switch
"Living room LED switch"
{channel="mcp23017:mcp23017:output1:output#A0"}
Contact
living_room_led_contact
"Living room LED contact"
{channel="mcp23017:mcp23017:input1:input#B0"}
The Input-Pin is connected to a button which switches a relay. This ensures, that the switch works without openhab or anything else. The following rule should change the lable of the switch in Basic UI from on to off and from off to on every time the hardware switch is used.
rule "living_room_led contact"
when
Item living_room_led_contact changed to CLOSED
then
if (living_room_led_switch.state == OFF) {
living_room_led_switch.sendCommand(ON)
}
else {
living_room_led_switch.sendCommand(OFF)
}
end
At this point a new problem is begins The reason for it is, that everytime I push the button the rule said to the switch to send a command which is not needed as I just want to change the “picture” of the switch in Basic UI. On the other side, when I use the switch of Basic UI to turn the LED on, the contact switches it off again. I hope I was able to describe it well. My question is:
How can I isolate the contact from the switch? At the end nothing should happen to the conntact when the switch in Basic UI is used but on the other hand I would like to see a change when the button is used.
Thank you!!!
BrainPain
Maybe try this thread.
If I’ve understood you correctly, you’re using the input pin to tell openHAB the state of a pushbutton. Whether openHAB knows about it or not, the button switches a relay? A pulse (latching) relay?
If that’s the case you are not really interested in the button. You want to know the relay state.
Good evening,
thanks for the reply. Meanwhile I found a solution and I want to summarize what I did. But first of all I want to thank the community for the support!!
1. Set-up
We installed for everything which can be switched in our house relay from Eltako (eS12-200-Uc) which are placed in a central controll box. Every switch in our house is wired with 24V and when pressed they give a short 24V-signal to the relay which switches the 220V for light etc… This works without any Raspberry Pi or something else. (This is very important as I still want to have light in case the Raspberry Pi is down). The aim was to use the 24V-cycle with the Raspberry Pi. The following wirering scheme shows what I did in my Test-set-up (Instead of 220V I used 24V and a LED this is much saver!!!).
Please find the corrected version below.
What happens at wicht event?
a) button is pressed
-
A signal is send to the relay which switches the relay and the light glows
-
A signal switches the optocoupler which isolates the Raspberry Pi from the 24V and a 3.3V Signal can pass the optocoupler and give a signal to the input pin B0 (It is important to set a pull-down resistor to this pin to prevent floating currents - thanks to the community for this hint!)
-
The 3.3V signal is used by openhab to change the symbol on the sitemap
b) Switching the switch on sitemap
-
A short 3.3V signal (100 milliseconds) is send from output pin A0 to the optocoupler
-
The signal let the 24V pass which switches the relay and the light is on or off
-
The switch shows the actual state of the light (on or off)
2. Installing the MCP23017-binding
This is the part which cost me a lot of energy. Unfortunately the version which can be installed via Paper UI leads to an error thus I put the “org.openhab.binding.mcp23017-2.5.3-SNAPSHOT.jar”-file into the addon-folder after uninstalling the binding in Paper UI. That’s it Furthermore wiringPi and so on needs to be installed and the user “openhab” needs to be added to group “gpio” and “i2c”. (To be honest, I don’t know, if the last two steps are really necessary)
3. The code in openhab
I use two MCP23017 one only for inputs (address 20) and one only for outputs (address 24). I use this set-up, because in future I will use several MCP23017 and I wanted to check, if everything works. This is why I created two things:
Thing mcp23017:mcp23017:input1 "MCP23017 Input 1" [address=20,bus=1] {
//input-Pins
Type input_pin : input#A0
Type input_pin : input#A1
Type input_pin : input#A2
Type input_pin : input#A3
Type input_pin : input#A4
Type input_pin : input#A5
Type input_pin : input#A6
Type input_pin : input#A7
Type input_pin : input#B0
Type input_pin : input#B1
Type input_pin : input#B2
Type input_pin : input#B3
Type input_pin : input#B4
Type input_pin : input#B5
Type input_pin : input#B6
Type input_pin : input#B7
}
Thing mcp23017:mcp23017:output1 "MCP23017 Output 1" [address=24,bus=1] {
//output-Pins
Type output_pin : output#A0 [default_state="HIGH"]
Type output_pin : output#A1 [default_state="HIGH"]
Type output_pin : output#A2 [default_state="HIGH"]
Type output_pin : output#A3 [default_state="HIGH"]
Type output_pin : output#A4 [default_state="HIGH"]
Type output_pin : output#A5 [default_state="HIGH"]
Type output_pin : output#A6 [default_state="HIGH"]
Type output_pin : output#A7 [default_state="HIGH"]
Type output_pin : output#B0 [default_state="HIGH"]
Type output_pin : output#B1 [default_state="HIGH"]
Type output_pin : output#B2 [default_state="HIGH"]
Type output_pin : output#B3 [default_state="HIGH"]
Type output_pin : output#B4 [default_state="HIGH"]
Type output_pin : output#B5 [default_state="HIGH"]
Type output_pin : output#B6 [default_state="HIGH"]
Type output_pin : output#B7 [default_state="HIGH"]
}
The first one for inputs and the second for outputs. It is important to set default_state=”HIGH”
After that the following items were created:
Switch
living_room_led_switch
"Living room LED switch"
Switch
living_room_led_state
"Living room LED switch contact"
Switch
living_room_led_command
"Living room LED command"
{channel="mcp23017:mcp23017:output1:output#A0"}
Contact
living_room_led_contact
"Living room LED contact"
{channel="mcp23017:mcp23017:input1:input#B0"}
But why three switches for on light? The reason is, that otherwise a click on “living_room_led_switch” would lead to a second triggering of the “living_room_led_switch” via contact, as the input gets an impulse, too. The task of the four items are the following:
living_room_led_switch: is shown on the sitemap and will trigger the rule “living_room_led switch” (see below) if used via Basic UI or whatever.
living_room_led_state: saves the state of the light (ON or OFF) and is used on the sitemap (e.g. visibility=[living_room_led_state==ON]
)
living_room_led_command: This switch is triggerd over a rule by the “living_room_led_switch” and is the only one which is connected to the thing (adress=24 => Output)
living_room_led_contact: This is the conntact wich is conected to the input (adress=20 => Input) and will trigger the second rule, if a button is pressed
Let’s have a look at the rules:
rule "living_room_led switch"
when
Item living_room_led_switch received update
then
living_room_led_command.sendCommand(ON)
Thread::sleep(100)
living_room_led_command.sendCommand(OFF)
end
rule "living_room_led contact"
when
Item living_room_led_contact changed to CLOSED
then
if (living_room_led_state.state == ON) {
living_room_led_state.sendCommand(OFF)
}
else
living_room_led_state.sendCommand(ON)
end
The rule “living_room_led switch” reacts on a press of “living_room_led_switch” and set “living_room_led_command” to state “ON” for 100 milliseconds. This is because the Eltako is a latching relay which reacts on short impulses. The second rule reacts on an input and changes, depending on the state of “living_room_led_state”, the state of “living_room_led_state” which is important for the switch which is shown on the sitemap:
sitemap Test label="Test" {
Frame label="Test" {
//Shows the switch depending on its state
Switch item=living_room_led_switch label="Licht ON" icon="switch-off" mappings=[ON="ON"] visibility=[living_room_led_state==OFF]
Switch item=living_room_led_switch label="Licht OFF" icon="switch-on" mappings=[ON="OFF"] visibility=[living_room_led_state==ON]
}
}
Both switches are the same with an different label
and mapping
via its parameter visibility
. On is shown if "living_room_led_state is “ON” and one if it is “OFF”.
3. And now?
I have to create a circuit board, solder it and bring it to from “dev” to “prod”. After everything is done (which can take a while) I will open a new thread in which I explain everything in detail
Once again thanks!
Best regards
BrainPain
Just for comparison, I’ll outline the rules I use with pulse relays.
I use modbus control, which means I can link my “monitor” input to a Switch type Item, and so I can get away with two Items per relay.
But the MCP23017 binding requires you to link inputs to a Contact type, not a Switch, so you do have to go with three Items as you have done.
There is careful use of command and postUpdate, and != ON rather than == OFF to avoid problems with NULL or UNDEF Items.
// this one goes on sitemap, gets commanded by motion rules, etc.
Switch Light_Master "master" {autoupdate="false"}
// this one is the simulated push button
Switch Light_Pulse "button" {channel="your:output:device"}
// this one is the feedback from the device
Contact Light_Monitor "sensing" {channel="your:input:device"}
// this rule avoids the need for any button pulse timer
rule "monitor light"
when
Item Light_Monitor changed
then
if (Light_Pulse.state == ON) {
// then it was an openHAB initiated switching
Light_Pulse.sendCommand(OFF) // stop pressing simulated button
} else {
// then it was a manual external change
trigger presence detection, cancel timers, etc. due manual activity
}
// now update the master
if (triggeringItem.state == CLOSED && Light_Master.state == ON) {
Light_Master.postUpdate(OFF)
} else if (triggeringItem.state == OPEN && Light_Master.state != ON) {
Light_Master.postUpdate(ON)
}
end
// this rule actions commands from UI or other rules
rule "do light command"
when
Item Light_Master received command
then
//only do it if state not already as commanded
if (receivedCommand.toString != Light_Master.state.toString) {
Light_Pulse.sendCommand(ON) // simulate button press
}
end
Suggested improvements -
It’s easy to apply the “Associated Items” Design Pattern here - that means just one set of rules can serve many sets of Items.
I actually put a failsafe expire on the pulse Item - if anything goes wrong, it turns off eventually
Switch Light_Pulse "button" {channel="your:output:device" , expire="1m,command=OFF}
Using this schematic diagram and selecting an adress other than 20 will shorten the 3.3v power supply from the PI; d’not know what the output will be;
The pull-down 1 resistor is no help; the way this diagram is designed, it will blow the collector-emittor junction of the optocoupler “input”
https://www.electronics-tutorials.ws/logic/pull-up-resistor.html
Hey rossko57, Hey Rik,
Thanks alot for your feedback.
At rossko57: I will have closer look at it later. I would Love to habe it easier.
At Rik:
What do you mean with shorten? I made the diagramm After I build and test the set-up. As the set-up workes with two mcp23017 I propably made a mistake with the schedul.
Thanks a lot!
What do you mean with shorten? I made the diagramm After I build and test the set-up. As the set-up workes with two mcp23017 I propably made a mistake with the schedul.
Had a closer look at it. The schedul is completly wrong I am sorry for it and will upload a new one during the next days.
Oké
Most of the elctronic I/O ports have these days internal weak pull-up resistors, they are only used for input biasing. So does the mcp23017; an exception are the address pins, which need to be externaly biased according following schematic:
This means that switching is always referenced to ground. Using this technique gives a better noise immunity but…
More importent are the programming faults making an input involuntarily as an output and set the output to 0Volt; this will destroy the circuit internaly. Direct switching from the PS can bring you in compromising situation. One can use the same technique to connect the optocoupler directly to the I/O pin with the emittor to ground.
Hello,
please find enclosed the corrected wirering scheme, as promised above. (I deleted the wrong one in my first post)
Testschaltung.pdf (19.9 KB)
Once again sorry for the wrong upload!
Best regards
BrainPain