Home Automation Domotica Forum Europe, Bwired Forum

I've been working on creating a Vera plugin to work with the OTG. This all works OK and I must say I'm very happy that I can now control my central heating via Vera! However unfortunately the responses the OTG sens are not unambiguous. Now I understand that this is a serial interface and there is normally only one master and one slave, but I've connected my OTG via an Ethernet->TTL device. One of the fun things of this is that you can connect from multiple sources (Vera, PC, etc.) to OTG. So multiple devices can send a command like 'PR=G' to the OTG. As a result they will all get the message '0' or '1' back.

The device that has issued the command can parse this, as it knows that it has sent 'PR=G'. However, the others do not and the command sent might just a well have been 'PR=T'.

Would it be possible to prefix all responses with the request? I.e. This would enable all listeners to process the information.

Since your ethernet/ttl device is the only thin which 'knows' about the multiple connections, in it's current state the gw won't be able to distinguish between them. The commands would have to be changed to allow the addition of a label... PR=<cmd>=<label> for instance..

The Gateway also does not need to know. It is not necessarily a problem that multiple devices can send commands (e.g. reporting commands). But is would help if the response is prefixed by the command sent, such that the listeners know the command that was sent.

I implemented it, a little bit differently than you requested, in firmware 4.0a9. I hope that will work for you.

Thanks! Even better to confirm what command has exactly been executed. I'll give it a try later this week.

I tried out the new responses of 4.0a9 and there is one response I don't understand.

When sending the command 'GW=1' the response is 'GW: G'. This is not consistent. One is also not allowed to send the command 'GW=G' (result: BV). Can this response be changed to return 'GW: 0' or 'GW: 1'?

I just reused the code from the PR=M command. But you are right, it's not very consistent. Fixed in firmware 4.0a10.