Yes, you can program an actual button with a virtual output in the nhc2 software.
But it will be detected in the binding as a generic action. I proposed to @Mherwege ready to make this a ‘switch’ so we can use it on OH.
That way you could actually use a Niko pushbutton to send an email, start a pump, open a garage door etc…
@bccrew @Nepomuk3000 You can actually. While it is detected as a pushbutton, and the AutoUpdate flag is set off by default for this type, you can override the AutoUpdate flag and put it to on. That will get you exactly what you need.
If you add an advanced action in the nhc2 software and assign a physical button of Niko (Player or Speler) to a virtual output (Check the list, it should be there), the controller will have an id for that action and it be communicated with the mqtt broker. The OH binding will pick it up and put it in the inbox.
Thanks @bccrew, unfortunately it’s not enougth to make me understand how it works…
Indeed, the action appeared in the inbox so I added the Thing but after that, I can’t find what to do…
In fact, I wanted to toggle a WeMo plug with a Niko pushbutton.
In OH, I have the WeMo Thing, the Niko PB Thing and created an Switch Item, added the Item to the WeMo and the PB things Channel.
In HABmin, when à toggle the test button of the WeMo Thing or the PB Thing, the WeMo plug toggle.
In HABMin, the test button toggle when I push the actuall PB but the WeMo stuff does not toggle 
I still need to find the time to test it better myself…
You will probably need to create a rule to act on what the status of the item is. When I press the pushbutton with virtual output, and then press it again I see 2 entries in the debug log.
Niko Home Control: received topic c2f2aacf-ba96-45ae-98d4-50e24f52f3e4/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"On"}],"Uuid":"159d4b87-acec-4ba3-98da-5aabded0ae1f"}]}]}
Niko Home Control: update channel state for 159d4b87-acec-4ba3-98da-5aabded0ae1f with 100
Niko Home Control: setting action 159d4b87-acec-4ba3-98da-5aabded0ae1f internally to ON
Niko Home Control: received topic c2f2aacf-ba96-45ae-98d4-50e24f52f3e4/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"Off"}],"Uuid":"159d4b87-acec-4ba3-98da-5aabded0ae1f"}]}]}
Niko Home Control: update channel state for 159d4b87-acec-4ba3-98da-5aabded0ae1f with 0
Niko Home Control: setting action 159d4b87-acec-4ba3-98da-5aabded0ae1f internally to OFF
Like @Mherwege said, you can enforce the auto-update status.
On a sidenote, @Mherwege this does not change anything regarding the status?
I still see
Niko Home Control: update channel state for 159d4b87-acec-4ba3-98da-5aabded0ae1f with 100
Niko Home Control: setting action 159d4b87-acec-4ba3-98da-5aabded0ae1f internally to ON
Niko Home Control: update channel state for 159d4b87-acec-4ba3-98da-5aabded0ae1f with 0
Niko Home Control: setting action 159d4b87-acec-4ba3-98da-5aabded0ae1f internally to OFF
I think the main problem is that the pushbutton with virtual output doesn’t generate an event so rules don’t work but I could be wrong…
A normal switch logs like this:
==> /var/log/openhab2/events.log <==
2019-02-20 22:54:13.009 [vent.ItemStateChangedEvent] - Lichtpunt_hobbyzolder changed from ON to OFF
The virtual output item doesn’t create this in the events.log
The secret will probably be to create a rule in OH that gets triggered on these kinds of events.
Maybe @Mherwege can clarify a bit more?
@bccrew @Nepomuk3000 I will have to look into this again.
The Autoupdate flag works from OH to the binding, i.e. it will tell OH if the status in OH needs to be flipped after switching the item in the OH UI. This is useful if there is no status to the thing. For example, an all off or scene, would not have a status. You would just trigger it.
In this case, on the Niko side, it has a status. That already goes back correctly to the binding. But the binding does not update the item state. So I need more than just playing with the Autoupdate flag. Forcing Autoupdate is only part of the solution. The state also needs to be passed on.
@bccrew @Nepomuk3000 I found a bug in the push-button handling. I just loaded a new version. Please try again.
This new version also includes support for motors (rollershutters). Happy to get feedback.
@Mherwege Nice, it’s working now.
2019-02-21 20:42:21.817 [vent.ItemStateChangedEvent] - ACTION1_Button changed from OFF to ON
@Nepomuk3000 You can trigger this kind of button with a simple rule now. In my case I configured the mail action in OH (for gmail you need to set up an application specific password).
rule "pushbutton.rules"
when
Item ACTION1_Button changed from OFF to ON
then
sendMail("myemail@gmail.com","Action Button","The action button has been pressed. The status is on")
sendNotification("myemail@gmail.com", "The action button has been pressed. The status is on")
end
The notification can be sent to the OH app for android/iOS.
I think in your case, you can use Item.sendCommand(ON) to trigger your Wemo plug. Please post your script if you get it to work 
Thanks
The rule seems strange to me but it finally works
rule "lampadaireON"
when
Item BTLampadaire changed from OFF to ON
then
BTLampadaire.sendCommand(ON)
end
rule "lampadaireOFF"
when
Item BTLampadaire changed from ON to OFF
then
BTLampadaire.sendCommand(OFF)
endRegarding motors, nothing seems to change with the new version.
There is nothing new in the inbox…
Did I do something wrong?
@Nepomuk3000 Did you execute a bundle:list command in the karaf console, what does it say for the nhc binding?
221 │ Active │ 80 │ 2.5.0.201902211239 │ Niko Home Control Binding
I guess this should be the latest version.
Did you try to manually look for things?
@bccrew you are right, I don’t have the last verison. How to stay up to date? Is it possible to clone the @Mherwege git repository?
@Nepomuk3000 That would be a bit harder… but check post 158. You confirmed that the pushbutton is working with your version of the binding and that was only fixed in the latest build?
The download link to the latest version is available in that post. If it still doesn’t work, you can clean out your events.log and openhab.log, restart openhab and let the binding start up. Then after a full initialisation, send both new logs in pm to @Mherwege. The device.list command should show us more details. Don’t forget to turn on TRACE debug level in the karaf console.
This version ;
218 │ Active │ 80 │ 2.5.0.201902091602 │ Niko Home Control Binding (md5sul of the jar : 7fa26d856ce33c81c7e6f96c2b8f199d)
works with my pushbutton but with a strange rule…
I now have the last version
220 │ Active │ 80 │ 2.5.0.201902211239 │ Niko Home Control Binding
but nothing seems to change regarding neither motors nor pushbuttons…
We need logs…
I understand it does not work. I cannot improve it without logs though. Test it and get me the logs, so I can see where it fails.
@Nepomuk3000 @bccrew I am not entirely happy with the behaviour of push buttons yet.
I see there are two cases:
You want to trigger something from a Niko button, but their is no state. The example is @bccrew sending a mail. Another example would be triggering a garage door motor relay. @bccrew can you test with configuring the button in the Niko system as a pushbutton (so in the Niko programming software)? I want to see what the logs say in this case.
A real state needs to be represented in OH. This is the example of @Nepomuk3000. I am honestly surprised about the need for these rules. Make sure the Autoupdate flag is off. Potentially, we need to play with the profile defined on the channel link. Make that follow for the Wemo. @bccrew this is again something you may want to investigate as well.
I want to come to a solution that does not need rules for this and has the state defined as it should be.
@Mherwege you are right that there are 2 scenario’s for the advanced action that is created in nhc2 software with a virtual output.
Niko uses the basicstate parameter in their “generic” types to distinguish if an item is on/off. Normally for a switcheable item like a light, they use the “Status” parameter.
Turn on a light, basicstate goes off, status goes on
Niko Home Control: received topic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"Off"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},{"Properties":[{"Status":"On"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]}]}
Turn off a light, basicstate goes on, status goes off
Niko Home Control: received topic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"On"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},{"Properties":[{"Status":"Off"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]}]}
But for the generic action type, you will see the following:
Press once:
Niko Home Control: received topic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"On"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]}]}
Press again:
Niko Home Control: received topic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"BasicState":"Off"}],"Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]}]}
With the current version of the binding, I tried forcing to make a switch from the thing and adding the autoupdate=false but it doesn’t change to always on.
Switch ACTION1 "ACTION1_Button { channel="nikohomecontrol:pushButton:443b0xxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:button", autoupdate="false"}
Press once:
ACTION1 changed from OFF to ON
Press again:
ACTION1 changed from ON to OFF
So, we can circumvent this type of behaviour now, by creating a rule that acts on both statuses. Is it ideal? No. Does it work? Yes 
As we know, there are several generic action types present:
+---generic - bose - audiocontrol - 10 UdmParameters
+---generic - coolautomation - hvaczone - 3 UdmParameters
+---generic - nikohomecontrol - windsensor - 5 UdmParameters
+---generic - nikohomecontrol - rainsensor - 4 UdmParameters
+---generic - nikohomecontrol - thermometer - 5 UdmParameters
+---generic - nikohomecontrol - lightsensor - 5 UdmParameters
+---generic - nikohomecontrol - humiditysensor - 5 UdmParameters
+---generic - nikohomecontrol - co2sensor - 5 UdmParameters
+---generic - nikohomecontrol - action - 3 UdmParameters
+---generic - sonos - audiocontrol - 74 UdmParameters
What I’m about to say is just guessing for now, but I think the UdmParameters are in fact the Basicstate options.
When the devices.list gets loaded from the broker, you can see this entry:
{"Properties":[{"BasicState":"Off"}],"Name":"ACTION1","Technology":"nikohomecontrol","Uuid":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","Identifier":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","PropertyDefinitions":[{"BasicState":{"Description":"Choice(On,Off,Triggered)","HasStatus":"true","CanControl":"true"}}],"Online":"False","Model":"generic","Traits":[],"Type":"action","Parameters":[{"LocationId":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},{"LocationName":"Home"},{"LocationIcon":"attic"}]}
My guess is that On,Off,Triggered corresponds to the 3 UdmParameters of the generic action. As I said, I’m just guessing for now. We’ll need more logs to see if this relation is correct.
Is this important? Maybe, it depends what other features you would like to see implemented in the future.
Just remember, that is it a virtual output. It doesn’t represent a real item within the Niko world, it’s just an UUID and in fact an “external” switch that we want to use for other purposes.
Hi,
I tried to upload logs but they are far too big for the forum that accepts very limited size…
How can I do?