Closed irqnet closed 6 years ago
To be a little more precise here the part of the log that let's it seem like the true
doesn't get translated correctly:
10/04/17 13:02:10.845 RPC Server (Port 2001): Info: Client number 128172 is calling RPC method: setValue (1) Parameters:
(String) ITD00000221:1
(String) STATE
(String) false
10/04/17 13:02:10.846 Module Intertechno: Info: STATE of peer 10 with serial number ITD00000221:1 was set to 0x00.
10/04/17 13:02:10.846 Module Intertechno: Intertechno CUL “CUL1”: Info: Sending (CUL1): F000F0000FF0
10/04/17 13:02:11.179 Intertechno packet received from 00000000 (RSSI: -74 dBm):
10/04/17 13:02:28.158 RPC Server (Port 2001): Info: Connection from ::ffff:192.168.21.20:33876 accepted. Client number: 128174
10/04/17 13:02:28.158 RPC Server (Port 2001): Info: RPC server client id for client number 128174 is: 17099
10/04/17 13:02:28.159 RPC Server (Port 2001): Info: Client number 128174 is calling RPC method: setValue (1) Parameters:
(String) ITD00000221:1
(String) STATE
(String) true
10/04/17 13:02:28.159 Module Intertechno: Info: STATE of peer 10 with serial number ITD00000221:1 was set to 0x01.
10/04/17 13:02:28.159 Module Intertechno: Intertechno CUL “CUL1”: Info: Sending (CUL1): F000F0000FF0
10/04/17 13:02:28.493 Intertechno packet received from 00000000 (RSSI: -74 dBm):
Depending on true/false it correctly shows 0x01
and 0x00
, but what is sent out to the device is F0
in both cases, even though it should be FF
when switching to on.
PS: This is when using the deprecated XML-RPC that's compatible to the CCU.
Hi,
but what is sent out to the device is F0 in both cases
In the RPC request, the value is a String, not a Boolean. That's why it's always interpreted as "false". So this is not an Homegear issue. But as you might be not the only one with that problem, in the next version String "true" is converted to Boolean "true" in this case.
Cheers,
Sathya
Just out of curiosity:
(String) false
-> "...was set to 0x00"
(String) true
-> "...was set to 0x01"
To me that looks like it's actually already getting it correctly, but not passed on correctly to wherever the Intertechno-magic happens. Or are those 0x values irrelevant in that case?
Indeed the converter already processed a String "true" correctly. But the module used the original value variable and there only the Boolean value. So the value was correctly stored in the database but wrongly sent to the device.
I'm trying to use the Homegear RPC API with HomeAssistant to switch my Intertechno devices. What I've found out is, that using the RPC API, i can not switch the devices on, but turn them of, no matter what value was used.
example:
Log Output using the setValue true in homegear (rc '$hg->setValue.....')
10/04/17 13:07:22.371 Module Intertechno: Intertechno CUL “CUL1”: Info: Sending (CUL1): F000F0000FFF
Log Output using the setValue true over API (from Home Assistant)
10/04/17 13:08:19.182 Module Intertechno: Intertechno CUL “CUL1”: Info: Sending (CUL1): F000F0000FF0
Log Output using the setValue true over API (from Home Assistant)
10/04/17 13:08:54.544 Module Intertechno: Intertechno CUL “CUL1”: Info: Sending (CUL1): F000F0000FF0
so in both cases using the API, there is F000F0000FF0 transfered, that means false, or turn off the switch.
Some more detailed failure analysis is done at the Home Assistant forum: https://community.home-assistant.io/t/using-homematic-intertechno-devices-with-homegear/28226