HDL Wireless Devices - Broadcast DryContact Status not recognized!

Martin Lang 10 months ago in Products / HDL-BUS Pro • updated by Slava Zhuravlev (expert) 2 months ago 32


ALL the new HDL Wireless devices have also a 4channel drycontact input. When an input is changed, the modules automatically send out a "Dry contact broadcast message". But iRidium does not recognize these messages. So you have to repeatly request the status of each channel on every wireless device over and over again. Please include the broadcast message datagram into iRidium PRO as soon es possible, so iRidium can react directly to an input change. And also decreasing the bus traffic!

I attached a screen shot. I have a status request for channel1 and channel2 running every 10 seconds. When the status changes, you see that the module automatically send out a broadcast of each channel that is changed (Line 39 and 51). In this case channel2 changed from closed to open and back again to closed.

So, iRidium has to process the OP-Code 15D0 correctly!

Best regards,

Martin Lang - MEB Austria


also a temperature broadcast code E3E5 is not recognized. :-(

Under review


about dry contact broadcast: I have just messaged to HDL support about this because HDL protocol says that 15D0 is status request and 15D1 is status response broadcast. On your screen there definitely should be response broadcast. So we have wrong description in protocol or something wrong with firmware that you use. 

So for now we are waiting for HDL support response.

About temperature broadcast: this is true we don't support the command for now. We will fix it soon.

We just got confirmation that there is a misstake in protocol. As soon as we get new version of the protocol we will fix the issue with dry contact broadcasting.

thx, please include also the wireless devices in the hdl device list. like the 1 channel curtain module with 4 additional dry-contact inputs, or the 1 channel and 2 channel relais module.

Hi, Martin.

We have added support of E3E5 code. It will be recognized if you replace your iridium.exe in iridium studio folder for the one that I attached to the message.


Tell us if it helped you or not.

hi, so this is the windows client right? would need it for the server too. thx.

Yes, it is. If it works on client we will send to you exe for server also.

hi, so tested your special version. is it working? yes and no.

broadcast temperatur receive is working, but only when you set the temperatur feedback channel to "read temperatur". it is not working when you set it to "read temperatur new". but when other devices on the bus doing also temperature requests, they mostly use the "read temperature new" method, also thats the standard format in iridium too. so, in my opinion there are two practical solutions:

1.) the "temperature broadcast" should always update the corresponding temperature channel of the device regardless of which method is selected "old" or "new". "temperature broadcast" messages (today) are always using the "old" temperature read format.

2.) maybe a better solution would be to not give the two options "read temperature" and "read temperature new" to be selectable, just make it "temperature response". and it should receive the "old" and the "new" temperature format and also the broadcast format too. because it doesn't make a difference in the result for the enduser. we just want the temperature.

for testing a server version, please send me a raspberry version. but i think you're doing it right.



thank you for the help in testing!

That is right. The E3E5 command is listed only in "Read temperature" section by HDL protocol. There is no such command for "Read temperature new".

We need to specify this question with HDL support.

Actually, i just saw it is a combined command. Look at the Specification below. The packet gives you 6 bytes. First is the channel number, second is the temperature in the "old" format. And additionally there are the 4 Bytes of the "new" temperatur float format.

I don't know if every device is sending out all the 6 bytes or some are just sending 2 bytes, but all the one's i'am testing here are doing 6 bytes.


You are right. We just need to parse the command for "Read temperature" and "Read temperature new". 

I will send to you the .exe file as the feature will be added.

Hello, Martin.

Can you try the iRidium32.exe file, please? 

HDL driver should parse E3E5 broadcast for "Read temperature" and "Read temperature new" now. 

i'll test it on the weekend, thx.

hi, doesn't work. i made two feedbacks on the same hdl device. first with "read temperature", second with "read temperatur new". A device that's broadcasting in the "old format" shows up only on the "read temperature" feedback, a newer device that sends the temperatur broadcast in the new format show up only on the "read temperature new" feedback.

the E3E5 broadcast message fills only the "read temperature" feedback, not the "read temperature new" feedback.


Thanks for the info. We will try to fix it.

Waiting for user's reply


Here is new .exe with bug fixed that you mensioned before. Check it out when you have time, please.


Hello, Martin. Did you have time to check it out?

not yet, i'll test it the next days.

hi, so tested it.

a READ TEMPERATURE fills the "Read Temperature" feedback

a READ NEW TEMPERATURE fills the "Read New Temperature" feedback

a TEMPERATURE BROADCAST fills both "Read Temperature" and the "Read New Temperature" feedback

is there a way to combine the two feedbacks internally? so, that there is only one "READ TEMPERATURE" feedback that gets all temperature feedbacks from the hdl bus? indepentent if it is a "old format" temperature response, the "new format" temperature response or a temperature broadcast in old or new format.

i have currently no device here that broadcast the temperature in the new format, so the broadcast i have tested was in the old format.

No, there is no way to make one universal "READ TEMPERATURE" feedback. HDL protocol has 2 different command types for old and new temperature. We don't know which one to take. 

So, can I consider that it works correct now?


Great! The update is included in last version of iRidium studio (12.12.2017 or past): http://www.iridiummobile.net/download/software/v3/

maybe we should change the topic of the thread, because the "dry contact broadcast" issue is still open. thx.


I will just reopen the topic.

We didn't get information about dry contact from HDL support. I will ask again, sorry.

We got confirmation that this is protocol error. Task to fix this is in queue.