An HASS service to send messages to nodes
-
@martinhjelmare But would be possible to change that attribute in automation? E.g., could the same switch receive several codes?
If not, this will not be a major improvement relative to the present situation...
I imagine it should work similar to how you can set brightness for a light in automation etc. So yes, you should be able to use logic to set different codes. Although, as I said, I haven't looked into all details, so we'll see what will be possible.
One problem I foresee is that it should preferably work as a push button, but switches in HA usually work as flip switches. Ie they stay in the state you switch them into. But I guess we want the device to turn on, send a code and then turn back to off state.
-
I imagine it should work similar to how you can set brightness for a light in automation etc. So yes, you should be able to use logic to set different codes. Although, as I said, I haven't looked into all details, so we'll see what will be possible.
One problem I foresee is that it should preferably work as a push button, but switches in HA usually work as flip switches. Ie they stay in the state you switch them into. But I guess we want the device to turn on, send a code and then turn back to off state.
@martinhjelmare In that case it will be VERY useful.
I have been playing with HA and LIRC on a Raspberry Pi (that acts as a remote near one of the new Samsung TVs) and found that the ability to send an IR code from HA is only useful for 'direct functions' like POWER, MUTE, SOURCE, VOL UP and VOL DOWN. Due to security reasons the appliance manufacturer's are limiting these cases and relying on context codes, like using arrows to select the appropriate choice, this makes the remote a not very useful concept to use in automation! Fortunately, if HA sends a code that represents the final goal (e.g. goto BBC), instead of the IR code, it is relatively easy to guess the appropriated steps in the node and send a sequence of codes to the appliance. The logic for that is better to be in the node not in HA because, even if in HA you know the sequence of IR codes, playing directly these codes in the node, make the process very unreliable (a small delay in the transmission and you will end up on Fox News instead!).
So your solution, in fact, is BETTER than a generic remote.
However, I don't see advantages to move 'IR send' to a switch, let it stay as a sensor whose state is the 'last code sent' together with a service that sends messages to that sensor... anyway this is a thing that will be useful for automation not so much as a UI gadget
-
@martinhjelmare In that case it will be VERY useful.
I have been playing with HA and LIRC on a Raspberry Pi (that acts as a remote near one of the new Samsung TVs) and found that the ability to send an IR code from HA is only useful for 'direct functions' like POWER, MUTE, SOURCE, VOL UP and VOL DOWN. Due to security reasons the appliance manufacturer's are limiting these cases and relying on context codes, like using arrows to select the appropriate choice, this makes the remote a not very useful concept to use in automation! Fortunately, if HA sends a code that represents the final goal (e.g. goto BBC), instead of the IR code, it is relatively easy to guess the appropriated steps in the node and send a sequence of codes to the appliance. The logic for that is better to be in the node not in HA because, even if in HA you know the sequence of IR codes, playing directly these codes in the node, make the process very unreliable (a small delay in the transmission and you will end up on Fox News instead!).
So your solution, in fact, is BETTER than a generic remote.
However, I don't see advantages to move 'IR send' to a switch, let it stay as a sensor whose state is the 'last code sent' together with a service that sends messages to that sensor... anyway this is a thing that will be useful for automation not so much as a UI gadget
Sensors are read only so it doesn't make sense to have an actuator like an IR send device be a sensor. That said, I'll know more how all this will work out once I start planning the code in detail. The IR receive should still be a sensor.
-
Sensors are read only so it doesn't make sense to have an actuator like an IR send device be a sensor. That said, I'll know more how all this will work out once I start planning the code in detail. The IR receive should still be a sensor.
@martinhjelmare Yes, I know that a sensor is read only, but it is important that the state is available on HA, how will you do it with a switch?
-
@martinhjelmare Yes, I know that a sensor is read only, but it is important that the state is available on HA, how will you do it with a switch?
The IR code will be available as a state attribute. You will be able to check it in automations with a template and
is_state_attrfor example. -
The IR code will be available as a state attribute. You will be able to check it in automations with a template and
is_state_attrfor example.@martinhjelmare Great!
-
PR here:
https://github.com/home-assistant/home-assistant/pull/2239Example sketch used for testing:
/* * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * http://www.mysensors.org/build/ir */ #include <MySensor.h> #include <SPI.h> #include <IRLib.h> #define SN "IR Sensor" #define SV "1.0" #define CHILD_ID 1 MySensor gw; char code[10] = "abcd01234"; char oldCode[10] = "abcd01234"; MyMessage msgCodeRec(CHILD_ID, V_IR_RECEIVE); MyMessage msgCode(CHILD_ID, V_IR_SEND); MyMessage msgSendCode(CHILD_ID, V_LIGHT); void setup() { gw.begin(incomingMessage); gw.sendSketchInfo(SN, SV); gw.present(CHILD_ID, S_IR); // Send initial values. gw.send(msgCodeRec.set(code)); gw.send(msgCode.set(code)); gw.send(msgSendCode.set(0)); } void loop() { gw.process(); // IR receiver not implemented, just a dummy report of code when it changes if (String(code) != String(oldCode)) { Serial.print("Code received "); Serial.println(code); gw.send(msgCodeRec.set(code)); strcpy(oldCode, code); } } void incomingMessage(const MyMessage &message) { if (message.type==V_LIGHT) { // IR sender not implemented, just a dummy print. if (message.getBool()) { Serial.print("Sending code "); Serial.println(code); } gw.send(msgSendCode.set(message.getBool() ? 1 : 0)); // Always turn off device gw.wait(100); gw.send(msgSendCode.set(0)); } if (message.type == V_IR_SEND) { // Retrieve the IR code value from the incoming message. String codestring = message.getString(); codestring.toCharArray(code, sizeof(code)); Serial.print("Changing code to "); Serial.println(code); gw.send(msgCode.set(code)); } } -
It works like a charm in version 0.22.1.
For complex sequences of IR codes, I just send a 'fake' code and then the node selects the appropriate sequence.
Thanks again!
Thanks for the feedback and live testing!
-
Let me complete the example given for the node when you use V_IR_SEND.
In order to send IR codes you need to transform the
code in an unsigned long:char ircode[11] = {0}; // in case your code takes the form of 0xE0E0FF0F ... if (message.type == V_IR_SEND) { String hexstring = message.getString(); hexstring.toCharArray(ircode, sizeof(ircode)); ... // get the code as an unsigned long unsigned long code = strtoul(ircode, NULL, 0); // with IRLib send the code to TV sendSAMSUNG(code); ...Very simple, ** but is hard to find an example**!