Nikobus compatibility OH2

nikobus
Tags: #<Tag:0x00007f01474b53f8>

(Peter Van Hanegem) #62

Well,

figured it all out. Can switch light by ‘button’ or direct by module.

The only thing, the switches on the site map do not know if the light is turning on/off by the physical button on the wall. Is there any way of scanning the modules and that the switches come in the right status ?

When reading back i see that @stefaanbolle has it figured out. Is there anybody who can set my on the right track.

I have my modules and physical buttons all set up in my .items map. I only stepped in at OH2 so i kinda missed the beginning and how things are were done.


(Rohnny Swennen) #63

Peter good news. yes this can absolutely be done. As a background the way it works is OH scans the modules so knows which outputs (lights) are on or off. This happens on a regular basis (parameter you can set). OH doesn’t know when you push a wall switch so here is how that works.

You need to configure the wall switch in OH
this is like Switch Kitchen_Light “Kitchen Light On/Off” { nikobus="#N003333" }

the address shows up in the log when you press the wall switch.

This doesn’t help in the update but here’s the trick, you can add in the configuration which module is influenced by this wall button. this can be one or multiple and it’s added at the end of the wall switch config as follows
Switch Office_Top_Left “Office and Kitchen Light On/Off” {nikobus="#N006884[C964-1,C964-2]"}

so for this example the first and last 6 outputs of module C964 are impacted (i.e. those outputs/lights are controlled by that wall switch).
Based on this OH will when it detects you press the wall switch now rescan those modules and update the outputs of the modules you have configured elsewere in the config. In the example it refers to

Switch light_office {nikobus=“C964:1”}
Switch light_hallway {nikobus=“C964:2”}
Switch light_living {nikobus=“C964:3”}
Switch light_kitchen {nikobus=“C964:4”}
Switch light_diningroom {nikobus=“C964:5”}
Switch light_toilet {nikobus=“C964:6”}

Makes sense?


(Peter Van Hanegem) #64

Thanks for the reply,

can you make a small example?.

i have physical switch in my .items:

Switch woonkameraan “Woonkamer aan” { nikobus="#N939FFA[0BE5:4]"}
Switch woonkameruit “Woonkamer uit” { nikobus="#ND39FFA[0BE5:4]"}

Switch Woonkamer “Woonkamer” {nikobus=“0BE5:4”}

What do i put in the sitemap, preferable only one switch

Woonkamer off - on

thanks again for the help

Edit, the switch in the sitemap get’s an update.

this is in my sitemap:

Switch item=Woonkamer label=“Woonkamer”

and it goes on/off like the light. Cool.

Side question. I also installed astro. So i get a time for sunset/rise.

I wantto make a rule so that the lights ouside goes on at sunset: Made a rule

rule "example trigger rule"
when
Channel 'astro:sun:05149f62:rise#event' triggered START 
then
************************************* 
end

What is the command for putting on the lights in a rule ?

`Switch buitenlichtaan “Buitenlicht aan” { nikobus="#N939FFA[0BE5:4]"}

???`


(Rohnny Swennen) #65

Not home this weekend but will send you example Monday or Tuesday.

Verstuurd vanaf mijn iPhone


(Peter Van Hanegem) #66

thanks (op voorhand)


(Rohnny Swennen) #67

Peter I think your items file should include something like this. I changed the naming slightly as I think structured naming will help you manage lots of switches. So my module outputs I call NB (from NikoBus) S1 (switch module 1 or 2 or 3 …) O4 output 4 followed by the name.
The wall switches NB (NikoBus) RB (Real Button) name of switch followed by the name in the nikobus software (so this BP9_A and B might differ in your case but it’s just to show you what a structured name could be, I assumed that it’s the A and B button of the wall switch but it really doesn’t matter as long as it’s a different name)

Note I did not give those a description as they will not show up in your sitemap.
The other mistake you made is adding the real output in there (4) you only need to refer to the module and left side or right side (1 for first 6 outputs or 2 for output 7 to 12)

The autoupdate = false is not really needed but it comes in handy if you soon move up to the next level and want to include one of these as push button in your sitemap because it has a lot of functions behing it in nikobus (an all lights off button for example or a scene.

Switch NB_S1_O4_Woonkamer “Woonkamer” {nikobus=“0BE5:4”}

Switch NB_RB_woonkamer_BP9_A {nikobus="#N939FFA[0BE5-1]", autoupdate=“false”}
Switch NB_RB_woonkamer_BP9_B {nikobus="#N939FFA[0BE5-1]", autoupdate=“false”}

Your sitemap will only include this
Switch item=NB_S1_O4_Woonkamer

Try the above above and it should put a switch in you sitemap you can turn the light on-off with and if you switch light with wall buttons status should update automatically in OH.

If this works remember you should configure output 1,2,3,5 and 6 of you nikubus module in the same way as you did with output 4 woonkamer as the nikobus oh command sets outputs per for all 6 outputs at once. So untill you have them all configure you might see your woonkamer light work well and other lights being turned off while you use woonkamer.

Regarding the astrosun. I never used that one, I see so many people struggle with it because of it’s compelxity in this forum that I postponed that one. So can’t help you with that but there are a lot of topics on that one.


(Peter Van Hanegem) #68

Cheers,

I sort of figured that out that it worked the way you wrote. I’m goning to make some adjustments to the items file.

About the astro rule, i have it working but i just need the ‘command’ sentence for nikobus.

MyItem.sendCommand(<new_state>)

is this then:
Switch item=NB_S1_O4_Woonkamer.sendCommand(on)
?

It’s just a lot of trail and error for me, but fun to do and joy if it works.


(Rohnny Swennen) #69

I’m using
sendCommand(NB_S1_O4_Woonkamer, ON)


(Peter Van Hanegem) #70

Happy 2018 everybody,

I just update to 2.2. And the status update does not seem to work anymore, more people noticed this or have a solution ?

UPDATE
Uninstall and instaal of the binding did the trick


(Peter Van Hanegem) #71

Other question:

Is it possible to use sliders to dim the light, i have 1 dimmodule and i use it now as a switch


(David Dassonneville) #72

Yes off course:

If you know the module address (explained in the binding docs)
Dimmer Living_Centraal “Living centraal” (Eetplaats,Lights) {nikobus=“XXXX:1”}


(T) #73

Hi,

I’m trying to use Openhab with Nikobus on a RPI. By running the “dmesg” command, I can see the physical connection of the Prolific cable to the RPI (ttyUSB0).
However the Openhab log tells me always that the “serial port USB0 is not found” and nothing works.

Any idea what the problem could be?

Big thank you!

Tijl

[ 1.025977] Freeing unused kernel memory: 1024K
[ 1.072207] mmc1: new high speed SDIO card at address 0001
[ 1.140164] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 1.140312] Indeed it is in host mode hprt0 = 00001101
[ 1.370480] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[ 1.370494] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.371372] hub 1-1:1.0: USB hub found
[ 1.371467] hub 1-1:1.0: 5 ports detected
[ 1.487255] systemd[1]: System time before build time, advancing clock.
[ 1.618849] NET: Registered protocol family 10
[ 1.639341] ip_tables: © 2000-2006 Netfilter Core Team
[ 1.665242] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[ 1.665783] systemd[1]: Detected architecture arm.
[ 1.667189] systemd[1]: Set hostname to .
[ 1.690167] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 1.820461] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 1.820475] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.823288] smsc95xx v1.0.5
[ 1.914034] smsc95xx 1-1.1:1.0 eth0: register ‘smsc95xx’ at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:35:91:6d
[ 2.010150] usb 1-1.5: new full-speed USB device number 4 using dwc_otg
[ 2.142436] usb 1-1.5: New USB device found, idVendor=067b, idProduct=2303
[ 2.142451] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.142460] usb 1-1.5: Product: USB-Serial Controller D
[ 2.142467] usb 1-1.5: Manufacturer: Prolific Technology Inc.
[ 2.262708] systemd[1]: Listening on udev Control Socket.
[ 2.263205] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[ 2.263439] systemd[1]: Listening on Journal Socket (/dev/log).
[ 2.264208] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 2.264933] systemd[1]: Created slice System Slice.
[ 2.267804] systemd[1]: Mounting POSIX Message Queue File System…
[ 2.268686] systemd[1]: Created slice User and Session Slice.
[ 2.365099] i2c /dev entries driver
[ 2.789386] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 2.885945] systemd-journald[126]: Received request to flush runtime journal from PID 1
[ 3.287499] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 3.655315] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 3.663475] usbcore: registered new interface driver brcmfmac
[ 3.808519] usbcore: registered new interface driver usbserial
[ 3.808603] usbcore: registered new interface driver usbserial_generic
[ 3.808687] usbserial: USB Serial support registered for generic
[ 3.816391] usbcore: registered new interface driver pl2303
[ 3.816486] usbserial: USB Serial support registered for pl2303
[ 3.816577] pl2303 1-1.5:1.0: pl2303 converter detected
[ 3.824529] usb 1-1.5: pl2303 converter now attached to ttyUSB0
[ 3.876189] brcmfmac: Firmware version = wl0: Aug 7 2017 00:46:29 version 7.45.41.46 (r666254 CY) FWID 01-f8a78378
[ 3.876959] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.41 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-08-07 00:37:47
[ 5.180192] Bluetooth: Core ver 2.22
[ 5.180266] NET: Registered protocol family 31
[ 5.180271] Bluetooth: HCI device and connection manager initialized
[ 5.180289] Bluetooth: HCI socket layer initialized


(KD) #74

Hi Guys

So I finally bought a PC-Link, so now trying to make it work.

I connected it to the bus, the seller gave me a cable for serial/USB and it is recognised on my PI2

Now, I can’t see anything else. Nothing in openhab, except an error when trying to refresh

2018-05-14 16:22:29.543 [ERROR] [ding.nikobus.internal.NikobusBinding] - Error occurred during scheduled status refresh.
java.util.concurrent.TimeoutException: No ACK received within timeout and retry count.
at org.openhab.binding.nikobus.internal.core.NikobusAckMonitor.waitForAck(NikobusAckMonitor.java:92) [231:org.openhab.binding.nikobus:1.11.0]
at org.openhab.binding.nikobus.internal.NikobusBinding.sendCommand(NikobusBinding.java:155) [231:org.openhab.binding.nikobus:1.11.0]
at org.openhab.binding.nikobus.internal.NikobusBinding$2.run(NikobusBinding.java:288) [231:org.openhab.binding.nikobus:1.11.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
at java.lang.Thread.run(Thread.java:745) [?:?]

Any idea ?


(KD) #75

You probably need to add something equivalent to this in your /etc/default/openhab2 file

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB_RFXCOM:/dev/ttyUSB_NIKOBUS"

in your case /dev/ttyUSB0 (I use UDEV)

my USD_RFXCOM works fine (thermometers, …)


(KD) #76

Ok, so somehow I made it working-ish

The first thing is that the services/nikobus.cfg seems to be broken. if I change the refresh, it keeps it at the default value.

Now, somehow it did connect on ttyUSB0 (while I configured ttyUSD_NIKOBUS, via UDEV rules)

but can get the debug to be meaningful :

16:58:01.408 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:01.409 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: �
16:58:01.435 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: �
16:58:01.437 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:01.459 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ����
16:58:04.177 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ��
16:58:04.179 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ~�
16:58:04.202 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: �������
16:58:04.210 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ~����
16:58:04.235 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ��
16:58:04.237 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: �
16:58:04.260 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: ��
16:58:04.267 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.286 [TRACE] [ikobus.internal.core.NikobusInterface] - Received: �
16:58:04.298 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.312 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.330 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.337 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.362 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.365 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:
16:58:04.394 [TRACE] [ikobus.internal.core.NikobusInterface] - Received:

Is there anything to be done on the PC-Link itself ?

2018-05-14 16:56:11.174 [DEBUG] [kobus.internal.core.NikobusInterface] - Found port: /dev/ttyUSB_RFXCOM x org.openhab.binding.rfxcom.internal.connector.RFXComSerialConnector
2018-05-14 16:56:11.176 [DEBUG] [kobus.internal.core.NikobusInterface] - Found port: /dev/ttyUSB_NIKOBUS x NikobusInterface
2018-05-14 16:56:11.179 [DEBUG] [kobus.internal.core.NikobusInterface] - Port not found during first attempt : null
2018-05-14 16:56:11.187 [INFO ] [kobus.internal.core.NikobusInterface] - Connected to serial port ‘/dev/ttyUSB0’
2018-05-14 16:56:11.188 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : ++++
2018-05-14 16:56:11.189 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : ATH0
2018-05-14 16:56:11.190 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : ATZ
2018-05-14 16:56:11.192 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : $10110000B8CF9D
2018-05-14 16:56:11.193 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : #L0
2018-05-14 16:56:11.195 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : #E0
2018-05-14 16:56:11.196 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : #L0
2018-05-14 16:56:11.197 [DEBUG] [kobus.internal.core.NikobusInterface] - Sending : #E1
2018-05-14 16:56:11.225 [TRACE] [kobus.internal.core.NikobusInterface] - Received: �
2018-05-14 16:56:11.227 [TRACE] [kobus.internal.core.NikobusInterface] - Received: �
2018-05-14 16:56:11.247 [TRACE] [kobus.internal.core.NikobusInterface] - Received: �
2018-05-14 16:56:11.399 [INFO ] [kobus.internal.core.NikobusInterface] - Connected to Nikobus :slight_smile:


(KD) #77

Doesn’t work for me, format is not supported :slight_smile:2018-05-15 14:18:05.512 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘nikobus’ of item ‘NB_RB_woonkamer_BP9_A’ could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: Could not determine item type from config: #NDAACCF[A810-4]
at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:51) [211:org.openhab.core.compat1x:2.2.0]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:341) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:310) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:195) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:377) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:314) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:143) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:247) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:311) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:209) [109:org.eclipse.smarthome.core:0.10.0.b1]
at java.lang.Thread.run(Thread.java:745) [?:?]
2018-05-15 14:18:05.635 [ERROR] [el.item.internal.GenericItemProvider] - Binding configuration of type ‘nikobus’ of item ‘NB_RB_woonkamer_BP9_B’ could not be parsed correctly.
org.eclipse.smarthome.model.item.BindingConfigParseException: Could not determine item type from config: #NDAACCF[A810-4]
at org.openhab.core.binding.internal.BindingConfigReaderDelegate.processBindingConfiguration(BindingConfigReaderDelegate.java:51) [211:org.openhab.core.compat1x:2.2.0]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:341) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:310) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:195) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:377) [135:org.eclipse.smarthome.model.item:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:314) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:143) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:247) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:311) [134:org.eclipse.smarthome.model.core:0.10.0.b1]
at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:209) [109:org.eclipse.smarthome.core:0.10.0.b1]
at java.lang.Thread.run(Thread.java:745) [?:?]
2018-05-15 14:18:16.456 [INFO ] [l.script.iPhoneKarl_Positio


(Daan De Winne) #78

Hello,

I did an update of openhab from 1.8.3 to 2.3.0.
My Nikobus is working fine but the scheduled refreshed don’t work.

When I press a Nikobus button, the light reacts and the switch Item in Openhab changes -> OK
When I press a Openhab (nikobus) Item, the lights react (Nikobus output reacts) -> OK
NO automatic refreshes of the Nikobus modules -> NOK

This is very annoying since I have some “go out after a delay” lights. the Items of this ones has to be automatically refreshed after a while (when the lights go off after the Nikobus delay). otherwise they go back on when an other output of the module is triggered by Openhab.

I got this out of my LOG:

2018-06-05 21:16:01.798 [ERROR] [ding.nikobus.internal.NikobusBinding] - Error occurred during scheduled status refresh.
java.util.concurrent.TimeoutException: No ACK received within timeout and retry count.
	at org.openhab.binding.nikobus.internal.core.NikobusAckMonitor.waitForAck(NikobusAckMonitor.java:92) [232:org.openhab.binding.nikobus:1.12.0]
	at org.openhab.binding.nikobus.internal.NikobusBinding.sendCommand(NikobusBinding.java:155) [232:org.openhab.binding.nikobus:1.12.0]
	at org.openhab.binding.nikobus.internal.NikobusBinding$2.run(NikobusBinding.java:288) [232:org.openhab.binding.nikobus:1.12.0]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

I see that other people also have this problem.
Is this issue already reported as a bug or something?
Is it really solved by uninstall and install the binding again? (I’am gonna try this later today)
or are there other solutions?


(KD) #79

Do you also have those kind of issues :
Binding configuration of type ‘nikobus’ of item ‘NB_RB_woonkamer_BP9_A’ could not be parsed correctly.

Switch NB_RB_woonkamer_BP9_A {nikobus="#NDAACCF[A810-4]", autoupdate=“false”}

Seems I can’t use the feedback as per the doc (on OH2.2)


(Daan De Winne) #80

Where dit you get this warning (in what log file?) and why do you use autoupdate=false ?

I do not use that with my Nikobus items I just have this:

Switch BP44_A {nikobus="#N94EE5A[7029-2]"}

I also think that you can’t use [A810-4] the “4” is not possible, I think it can only be 1 or 2. 1 for output 1 to 6 and 2 for output 7 to 12.


(KD) #81

Ok, so for the autoupdate=false, it is because all my commands are inverter (click once, it sets ON, click another time, it sets OFF) (not a button for ON and another for OFF, just inverter), so my button on OH should have that autoupdate=false

Now, for the Switch config, for what I understand, the switch is equivalent to a nikobus physical button (that sends a command to a module)

My Switch NB_RB_woonkamer_BP9_A would send the signal to nikobus, configured on the modules to invert the position on Module A810 slot 4. For what I understand from the documentation, what I put between [] should be the physical port impacted by this switch, so that it can have feedback ?

Switch NB_RB_woonkamer_BP9_A {nikobus="#NDAACCF[A810-4]", autoupdate=“false”}

In clear, what I wanted is to be able to get on my switch NB_RB_woonkamer_BP9_A is the ON/OFF state of the module that was impacted by the command NDAACCF

IF my config is bad, please let me know how to fix it

Here is my module definition :

Group gNikobusModulesB "Module B" <light> (gNikobusModules,gNikobusInit)

Switch C_N_B_1  "B 1 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:1"}

Switch C_N_B_2  "B 2 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:2"}

Switch C_N_B_3  "B 3 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:3"}

Switch C_N_B_4  "B 4 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:4"}

Switch C_N_B_5  "B 5 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:5"}

Switch C_N_B_6  "B 6 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:6"}

Switch C_N_B_7  "B 7 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:7"}

Switch C_N_B_8  "B 8 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:8"}

Switch C_N_B_9  "B 9 " <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:9"}

Switch C_N_B_10 "B 10" <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:10"}

Switch C_N_B_11 "B 11" <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:11"}

Switch C_N_B_12 "B 12" <light> (gNikobusModulesB,gHistory,gNikobusInit) {nikobus="A810:12"}