#Knx
frank vector
Ok. Do you use routing or tunneling to connect to your bus?
Do you know if your installation has multiple lines?
wet pine
tunneling (it's the default, right?) And it should be a single line, it's a new install and it's not that big of a house
it would be weird to have multiple lines
frank vector
Some have a dedicated line for outside devices
Try the knx.read service and set up debug logging (see documentation)
The telegram should appear there
wet pine
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Outgoing" source_address="0.0.0" destination_address="5/2/4" payload="<GroupValueRead />" />
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.knx] Sending: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="39" sequence_counter="70" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.1")" DestinationAddress="GroupAddress("5/2/4")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.raw_socket] Received from ('192.168.1.200', 3671): 06100421000a04274600
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_ACK" Reserve="0" TotalLength="10" />
body="<TunnellingAck communication_channel_id="39" sequence_counter="70" status_code="ErrorCode.E_NO_ERROR" />" />
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.raw_socket] Received from ('192.168.1.200', 3671): 061004200015042798002e00bce011012a04010000
2021-08-03 21:47:38 DEBUG (MainThread) [xknx.knx] Received: <KNXIPFrame <KNXIPHeader HeaderLength="6" ProtocolVersion="16" KNXIPServiceType="TUNNELLING_REQUEST" Reserve="0" TotalLength="21" />
body="<TunnellingRequest communication_channel_id="39" sequence_counter="152" cemi="<CEMIFrame SourceAddress="IndividualAddress("1.1.1")" DestinationAddress="GroupAddress("5/2/4")" Flags="1011110011100000" payload="<GroupValueRead />" />" />" />
reading a github issue seems that ErrorCode.E_NO_ERROR means it all went well
so I suspect the problem happens decoding the response. I know the response is 2bytes, and I set it to illuminance, but the values I get are somewhat unexpected
disregarding that they don't update, when it's pitch black it reads 100lx, and when it's moderately lit, 1009lx
but I never saw any other value
frank vector
so... the first is the outgoing telegram, the second the ACK received from (I guess) the tunnelling server
the third is, again, a confirmation frame from the tunneling server. This is normal.
but there is no answer whatsoever.
maybe the sensor is not set up (ETS) to respond to GroupValueRead requests. There is a flag to be set (read-flag)
are other sensors/devices working properly?
wet pine
2021-08-03 22:01:52 DEBUG (MainThread) [xknx.telegram] <Telegram direction="Incoming" source_address="1.1.34" destination_address="5/2/4" payload="<GroupValueResponse value="<DPTArray value="[0x36,0x2a]" />" />" /> isn't this a response?
this is a combines motion/illuminance sensor, and the motion part at least is working well
frank vector
yep thats it
wet pine
0x36,0x2a those two bytes should be decoded as a value
frank vector
what is a combined motion
wet pine
I mean that is a ceiling mount sensor that reports both movement and illuminance
frank vector
ah sorry, I thought telegram, not device
can you copy and paste the sensors config please?
wet pine
right now all I have is a text version of the ETS config, this being the only line for the sensor:
Escenas.Detectores.5/2/4 lux Detector Hall Uncertain (2 Byte) Low
frank vector
no, I mean the HA config
wet pine
ah
- name: "Luminosidad Recibidor"
state_address: "5/2/4"
type: illuminance
sync_state: 1
I tried sync_state: 1 in an attempt to force reading the value
wet pine
by reading the docs I understood that a number would be assumed as expire 1
but I also tried expire 1 with identical results
frank vector
yes, numbers between 2 and 1440
thats odd. expire 1 should work...
(but its too much... only do this for testing purposes)
frank vector
disregarding that they don't update, when it's pitch black it reads 100lx, and w...
(0x36, 0x2A) is 1009.92 - just as you stated before.
maybe the sensor is defect.
what model is it?
frank vector
you can try to light it with a torch / turn off the light and knx.read again - the value of the Response should change. If not tell your installator
wet pine
I suspect the error is how the 2 byte value is being decoded, but I'll ask them directly
frank vector
(if you only set xknx.telegram logger to default logs will be better readable)
nope, this works fine
... if it is a 2byte float
wet pine
thanks for your help anyway, I suspect it might be misconfigured or something, I'll ask the installer to join the VPN and check it remotely
other than that, the system ir working very well and everything until now integrated with home assistant like a charm
frank vector
👍
wet pine
I only regret that not every light in the home is dimmable, and in hindsight it should have been
frank vector
I know that feeling 🤣
wet pine
motion triggered lights in the hallway are way too bright and flash me too hard for a night walk
frank vector
Feel free to join https://discord.gg/Dn8AA2K7 for HA knx related questions
I've modified mine to be DALI-dimmable. It's a bunch of work but turned out really nice
Costs about 30€ per light and a Dali gateway.
wet pine
I have a knx-dali gateway, but not all lights are were designed as dali because, well, it's 80+€/light
so some are just in an on/off circuit
I'm not sure I'll be able to make those dimmable
there might not be a dali cable nearby
frank vector
I've changed the led drivers to Osram Oti. Every led should be dimmable that way if you can put the new driver somewhere
wet pine
I happen to have osram (ledvance) lights
frank vector
Yeah, pulling the cables through conduit was the hardest part