433mhz, infrared IR to and from MQTT on ESP8266

Third party integrations
423

In most of the situations you wouldn’t need a casing. IR signal won’t pass through most of the ABS boxes, however 433 mhz would do (433mhz would go even through spray paint if you need a casing in a different colour).

I have all the components simply hanging on (without a breadboard). If trying to keep up with the development of the project you would need to remove the micro-controller at least twice per day for adding or removing components or flashing new firmware (it’s really not set and forget). At the moment the focus is on functionality rather than prettiness.

But if you’re really keen on keeping things tied up look on boxes of this size or larger (it is barely useful for NodeMCU without breaking any pin but for WeMos R1 mini is perfect):

424

Hi Petrica - thanks for the reply. I was just trying to make it more cosmetic (wife friendly!) :slight_smile: if the breadboard etc is going to be sat in the lounge in view of the TV

425

If IR is the main culprit then use slightly longer cables to connect the IR receiver/blaster (have the main box outside view in a cabinet or taped right under the table) and then use isolating tape in the color of the furniture to cover the connecting cables. R1 mini are quite ok in terms of size.

You could point the IR blaster towards the device you want to control in a dead angle (as far I have seen it has a significantly reduced range than a regular, commercial IR remote but it would still go to 1 - 1.5 m).

For RF gateway simply place it out of sight :slight_smile:

1 Like
426

Hello, here is some insight about the support for kaku,

427

Can anybody tell how to retain the sensor status when HA is restarted the state turn back to off even when windows is open when HA restarts.My configuration is like -
binary_sensor.yaml -

- platform: mqtt
  name: Hall Window
  state_topic: "home/433toMQTT"
  command_topic: "home/MQTTto433" 
  payload_on: "11775242"
  payload_off: "11775246"
  optimistic: true
  retain: true

customize -

 binary_sensor.hall_window:
    friendly_name: Hall Window
    assumed_state: true
    icon: mdi:window-closed
428

See

429

Hi

Any ideas why my Serial Monitor is completely blank? Baud etc are matched - everything compiled and uploaded ok. Have connection status of online:
home/OpenMQTTGateway/LWT Online

430

Hi,

There isn’t much info provided. Try to check the entire chain (post printscreen/picture of modules if still not solved). Can think of the followings:

What baud rate have you used for serial monitor connection (not the one used for sketch uploading)? What is the software version loaded? What modules do you have (for gateway and for sensors)? Are the pins connected properly? etc

Are there any other messages in the MQTT topic from the gateway?

431

@Petrica is that any way to make ESP 8266 reboot when I get “home/OpenMQTTGateway1/LWT Offline” from the MQTT boker?

432

@jxjhheric

Hi,

I’m unsure whether there is a watch-dog functionality in the gateway (most of the code it’s Chinese for me anyway :smiley: ) however I’m using a cheap 433 Mhz socket to reboot one of the NodeMCUs. I have it connected with some other automation however you could do it as following. You can remove the entire condition part from the automation (I have different settings for night and day as during night receiving an IFTTT notification wouldn’t help me while I’m asleep :slight_smile: ) thus it will restart regardless of the hour. Also, remove the first part from the action if you don’t have IFTTT set. Check the MQTT topic for the actual payload (remember that MQTT is case sensitive).

Binary sensor:

- platform: mqtt
  state_topic: 'home/OpenMQTTGateway1/LWT'
  name: 'Gateway1'
  payload_on: 'Online'
  payload_off: 'Offline'

Automation:

- alias: RestartGateway1Daytime
  initial_state: 'on'
  trigger:
    - platform: state
      entity_id: binary_sensor.gateway1
      to: 'off'
      for:
        minutes: 1
  condition:
    condition: and
    conditions:
      - condition: state
        entity_id: sun.sun
        state: 'above_horizon'
  action:
    - service: ifttt.trigger
      data: {"event":"gateway1off", "value1":"gateway1off"}
    - service: homeassistant.turn_off
      entity_id: switch.rs1
    - delay: "00:00:05"
    - service: homeassistant.turn_on
      entity_id: switch.rs1
1 Like
433

Thanks for your reply，I’m Chinese，I can read Chinese，if there is something Chinese doc，you can send it to me。

1 Like
434

However, I think that there’s still the possibility of OpenMQTTGateway.ino being written in Japanese and User_config.h in Klingon :slight_smile:

2 Likes
435

Hi people,
I could set the 433Mhz part and it’s working fine sending and receiving codes.
I was planning to add the garage door automation to HA using this gateway and it works fine triggering the door.
But I found a funny behavior on the other hand. As soon as a code is sent through the gateway, the hand held remotes got dramatically reduced in coverage. This is not happening after a reboot of the nodemcu while a code is not sent. As soon as a code is transmitted, I have to get to 1 meter or less to the door in order to make the remotes to work (tried 3 different ones and changed batteries also).
Looks like the transmitter keeps transmitting noise of something that causes interference on the receiver.
Another test performed was to remove the input pin of the Tx module and the issue dissapears inmediatly. As soon you connect it back, the issue is back if the node is not restarted, tried also several power sources to avoid ripple to cause the issue.
Any hint on what can be happening?.
Is there a way to mute or reset Tx after a code has been sent?.
Thanks!!
Adrian

436

I think there shouldn’t be any noise sent after a successful code broadcasting.

What RF modules are you using? There are some cheaper modules that are quite bad.

Can you test with the RF modules on a different gateway or use it as a receiver to check if any code is still sent?

If the Tx module is still active you would have the code received at each 3 seconds (the default timeout period if you didn’t modify it).

437

Hi Petrica,
The modules I am using are cheap generic ones. I will have to purchase other ones to test if they are the cause. Note anyway the issue dissapears when the Tx module input is removed, but the module power is still on.
I will try other nodemcu’s just in case.
I don’t think the Tx module keeps transmitting codes after a command is sent, at least it is not repeating the same code, since the door is no stopped or reopened, but clearly there’s some interference present after the the code is transmitted. I don’t have an spectrum analyzer (whish I have one!!) or something to see what is being transmitted after the command is sent.
I’ll keep doing test and post the results. I would like to try also a way to disable or reset the Tx port on the code side to see if it helps.
Regards
Adrian

438

Please test the last version of the master to see if it improves something

439

Can I modify V 4.0 BT ino as you done, and flash that ?

440

Yes you can do this also

441

I’ve been using the latest build. And im having alot of disconnects with my nodemcu ESP8266-12f. I tryed different AP’s, tryed different nodemcu’s and all behaving the same way. With pinging I get huge latency (1000+ ms). After a while the ping becomes normal again. This repeates every 5-10 minutes.

Any suggestions how I can fix this?

442

could you clarify the different gateways and sensors you are using?
when you said the latest build is ti the one of this morning?