This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm that you accept these cookies being set.

Wiser for KNX virtual object problem
#1
Hello,

we are experiencing something strange with this device: one virtual object (32/1/24 but I don't think that is really relevant) kept triggering on (it is a 1 bit object) by itself after a while but it's not linked to anything in particular, no Scenes, no scheduler, no scripts and even no KNX/TP bus (we already tried to phisically disconnect it).

After we factory reset the device and reupload the configuration the problem is gone, anybody experienced that kind of behaviour?

Is there a procedure to avoid factory reset?

Thank you
Reply
#2
Set log to it and tell us what the log says. There must be a reason why you have it.
------------------------------
Ctrl+F5
Reply
#3
I would like to, but it's impossible to reproduce the problem right now, we tried to analyze everything before factory reset but we didn't find anything.

I know it has to be a reason for that, I just wanted to know if anybody has experienced that kind of problem.

Since it seemed to work as a pattern (about 1 minute) we tried to see if there was a scheduled process or something similar (strange since it was a brand new device, so it was a fresh programming) but, obviously, nothing.
Reply
#4
Daniel is right here, the only way to find out who is sending is to enable logging. Then in Object logs tab you will see local(sender) in the source address column. Possible values for the sender field:
Code:
bus = knx bus (ip or tp)
bt = bluetooth
bn = bacnet
mb = modbus
en = enocean
wl = lm wall
rc = reactor
ek = ekey
w1 = 1-wire
sc = scenes
se = event script
ss = scheduled script
sr = resident script
us = user interface / visualization
rm = remote services
ap = apps
po = group monitor object polling
dl = dali
Reply
#5
I can't do it now, if the problem comes back I will surely do.

I can only tell that when we checked (from ETS bus diagnostic) it says that wiser itself sent the message on bus, but after factory reset and reupload of the same configuration the problem is gone.

Thank you anyway.
Reply


Forum Jump: