Hello,
thanks for this detailled feedback!
Regarding the error when compiling on arduino mega it is possible you don’t have the last version of the library, try to download it from here.
I just retried and it compiles ok on my environment.
I will take a look to the others points tomorrow.
I have garage door that I want to add control to open/close from HA using OpenMQTTGateway.
I tried to decode the current remote control and i get the following readings on the receiver frm mqtt:
home/OpenMQTTGateway/LWT Online
home/433toMQTT/protocol 6
home/433toMQTT/bits 28
home/433toMQTT/length 471
home/433toMQTT 181222222
When I try to run the following command:
mosquitto_pub -t home/commands/PLSL_471/433_6/BITS_28 -m 181222222
I get the following on serial monitor:
Hey I got a callback
RF Protocol number:
6
RF Pulse Length:
471
MQTTtoRF user parameters
6
471
24
MQTTtoRF OK and ack published
181222222
Although the command is set as BITS_28, the transmitted pattern appears to be of 24 bits.
is there a limitation on the advanced parms to be used. How can I check what posible values can take each parm to see if the combination of protocol, pulse length, bits and payload are alowed?.
I did several checks and tryed several codes with no success at all.
Thanks for your help.
Adrian
Hello,
No limitation below 32 bits, but a mistake in the doc😒 the key for bit length is RFBITS_ and not BITS_ , the example in the docs is corrected
Hello,
I could modify the addon to publish adc reading only when there is a change in a certain limit, do you think it is interesting ? Or let the choice between this reading method and the regular one.
Hi,
I think it would be great to have also the option to send the reading when it reaches a threshold.
Although I didn’t used any scientific method for calibrating max and min values (I’ve first completely covered the module then used a flashlight directly pointed to it) I did get to reasonable values.
A funny fact: I have two identical cheap LDR modules (as far as I can tell they are identical, because there is no marking on either of them) however they are wired internally in reverse. With one I had to subtract the reading from 1024 while for the other I could use it as is.
Thanks for your work, it’s working, but I get wrong status randomly, that is nobody there, the PIR show true
I am also have the same issues
I have an issue on the NodeMCU boards I have: on both v0.4 and 0.3 bluetooth module (non-genuine HM10) and (occasionally) RF receiver (superheterodyne type) the MQTT connection gets reset. This does not trigger full reboot of NodeMCU but only disconnects the MQTT connection and reconnects and it takes a few seconds (3 - 4 at max) to reconnect.
My MQTT show the signal well, but in HA, the status don’t update.that’s usually happens after hours, restart HA the status updates correctly, and after hours, the issue appears again
I updates the mosquito, change to the emmberd boker, setup HA again… the issue is still there:sob:
My problem is that the Bluetooth module resets the MQTT connection for a brief time (during which it doesn’t send any message to MQTT broker from other modules connected to that NodeMCU either). If you can see the MQTT updates in the desired topics it is more likely an issue with either HA or MQTT rather than the NodeMCU itself.
Does the HA work reliably?
Do you see any errors in the frontend pertaining to the MQTT?
Do you have the possibility of installing a MQTT broker on a separate unit (either a second Rpi or a full Linux PC)? At least to identify where the problem resides.
I’ve had problems with the embedded MQTT broker included in the AiO base at some point (as it is quite limited in robustness). I went with installing a broker on a different Rpi (v1) and I didn’t had any issue with MQTT since. Rpi v1 is more than sufficient for running a MQTT broker with 10-15 different clients updating topics each second.
HA work well, there is no errors about MQTT in HA logs, after last MQTT message, there is no more. MQTT logs are no problem.so I don’t know who is wrong I will setup new mosquito in another machine to check
I was finally able to get this working with the Wio Link. For reference I have the HM-11 module connected to pins 12/13 on the Wio board, labeled as Digital1
With a Serial Converter, you can get console output from the UART0 port on the board.
Great thanks for the feedback!
Do you have different PIR to test with, I don’t reproduce this
Thanks 1technophile.
Is working now!!
Regards.
Adrian
Previously, I used another code and work properly you could look at this code:https://github.com/mertenats/Open-Home-Automation/tree/master/ha_mqtt_binary_sensor_pir
Did you play with hc sr501 sensibility ?
sorry, I did not understand what you mean,
I originally use PIR with nodemcu with this code , https://github.com/mertenats/Open-Home-Automation/tree/master/ha_mqtt_binary_sensor_pir. Working well.
now I want to join the Bluetooth module, use openmqttgateway project, so I can use Bluetooth, pir together, but now the PIR module get wrong status randomly.
By the way, This situation also appears in the project easyesp
PIR module has two knobs (and also a jumper) that you could use for the adjustment of sensitivity and time delay between reporting (see below).
But first of all: are you using a good power source? If available, use an Apple 5V USB charger with a good Micro-USB cable. There are a lot of issues with low quality power sources.
Have you got the PIR power wired to anything else? Another sensor perhaps or the bluetooth module, if yes then use a different power pin on the node mcu for each device, then you shouldn’t get any false readings from the PIR.Or at least use a separate power pin for the PIR only.
I’m interested in building this project myself.
What boxes/cases are you guys using to house the circuitry? Will the IR signal go through plastic ABS type boxes?