emonTH2 communication with pi2 dropping out

Good morning. Hope you can help with this issue. I have a pi2 with 3 no emonTh2 temperature sensors. Configuration file as follows

#######################################################################
#######################      emonhub.conf     #########################
#######################################################################
### emonHub configuration file, for info see documentation:
### https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
#######################################################################
#######################    emonHub  settings    #######################
#######################################################################

[hub]
    ### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
    loglevel = DEBUG
    autoconf = 0
### Uncomment this to also send to syslog
# use_syslog = yes
#######################################################################
#######################       Interfacers       #######################
#######################################################################

[interfacers]
    ### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
    [[EmonPi2]]
        Type = EmonHubOEMInterfacer
        [[[init_settings]]]
            com_port = /dev/ttyAMA0
            com_baud = 115200
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            subchannels = ToRFM12,
    

    [[SPI]]
        Type = EmonHubRFM69LPLInterfacer
        [[[init_settings]]]
            nodeid = 5
            networkID = 210
            resetPin = 24
            selPin = 16
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
    
    
    [[MQTT]]
        Type = EmonHubMqttInterfacer
        [[[init_settings]]]
            mqtt_host = 127.0.0.1
            mqtt_port = 1883
            mqtt_user = emonpi
            mqtt_passwd = emonpimqtt2016
        
        [[[runtimesettings]]]
            pubchannels = ToRFM12,
            subchannels = ToEmonCMS,
            
            # emonhub/rx/10/values format
            # Use with emoncms Nodes module
            node_format_enable = 0
            node_format_basetopic = emonhub/
            
            # emon/emontx/power1 format - use with Emoncms MQTT input
            # http://github.com/emoncms/emoncms/blob/master/docs/RaspberryPi/MQTT.md
            nodevar_format_enable = 1
            nodevar_format_basetopic = emon/
            
            # Single JSON payload published  - use with Emoncms MQTT
            node_JSON_enable = 0
            node_JSON_basetopic = emon/
    
    [[emoncmsorg]]
        Type = EmonHubEmoncmsHTTPInterfacer
        [[[init_settings]]]
        [[[runtimesettings]]]
            pubchannels = ToRFM12,
            subchannels = ToEmonCMS,
            url = https://emoncms.org
            apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
            senddata = 1    # Enable sending data to Emoncms.org
            sendnames = 1    # Send full input names (compression will be automatically enabled)
            interval = 30    # Bulk send interval to Emoncms.org in seconds
    
    [[DS18B20]]
        Type = EmonHubDS18B20Interfacer
        [[[init_settings]]]
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            read_interval = 10
            nodename = sensors
# ids = 28-000008e2db06, 28-000009770529, 28-0000096a49b4
# names = ambient, cyl_bot, cyl_top


    [[MBUS]]
        Type = EmonHubMBUSInterfacer
        [[[init_settings]]]
            device = /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_DUEIb11CN11-if00-port0
            baud = 2400
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            read_interval = 10
            validate_checksum = False
            nodename = MBUS
            [[[[meters]]]]
                [[[[[heatmeter]]]]]
                    address = 1
                    type = standard

    [[SDM120]]
        Type = EmonHubMinimalModbusInterfacer
        [[[init_settings]]]
            device = /dev/serial/by-id/usb-1a86_USB_Single_Serial_54D2042866-if00
            baud = 2400
        [[[runtimesettings]]]
            pubchannels = ToEmonCMS,
            read_interval = 10
            nodename = sdm120
            [[[[meters]]]]
                [[[[[controls]]]]]
                    address = 1
                    registers = 12, 72
                    names = Power, Energy
                    precision = 1, 3
                [[[[[outside]]]]]
                    address = 2
                    registers = 12, 72
                    names = Power, Energy
                    precision = 1, 3
                [[[[[heater]]]]]
                    address = 3
                    registers = 12, 72
                    names = Power, Energy
                    precision = 1, 3
                [[[[[immersion]]]]]
                    address = 4
                    registers = 12, 72
                    names = Power, Energy
                    precision = 1, 3

#######################################################################
#######################          Nodes          #######################
#######################################################################

## See config user guide: https://github.com/openenergymonitor/emonhub
## If autoconf is enabled above, node configuration will automatically
## populate based on templates listed in available.conf

[nodes]
    [[23]]
        nodename = emonth2_23_living
        [[[rx]]]
            names = temperature, external temperature, humidity, battery, pulsecount
            datacodes = h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, %, V, p
    [[24]]
        nodename = emonth2_24_bedroom
        [[[rx]]]
            names = temperature, external temperature, humidity, battery, pulsecount
            datacodes = h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, %, V, p
    [[25]]
        nodename = emonth2_25_crispin
        [[[rx]]]
            names = temperature, external temperature, humidity, battery, pulsecount
            datacodes = h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, %, V, p

Communication with the sensors dropped out again last night. Signal strengths were -35, -43 and -48 at the time. Emoncms log as follows.

2024-11-13 18:57:20.-375|WARN|emoncms_mqtt.php|Starting MQTT Input script
2024-11-13 18:57:20.-217|WARN|emoncms_mqtt.php|Not connected, retrying connection
2024-11-13 18:57:20.-205|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2024-11-15 17:33:00.-102|WARN|emoncms_mqtt.php|Starting MQTT Input script
2024-11-15 17:33:01.035|WARN|emoncms_mqtt.php|Not connected, retrying connection
2024-11-15 17:33:01.047|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2024-11-15 17:57:17.-260|WARN|emoncms_mqtt.php|Starting MQTT Input script
2024-11-15 17:57:17.-185|WARN|emoncms_mqtt.php|Not connected, retrying connection
2024-11-15 17:57:17.-173|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2024-11-15 18:01:14.024|WARN|emoncms_mqtt.php|Starting MQTT Input script
2024-11-15 18:01:14.112|WARN|emoncms_mqtt.php|Not connected, retrying connection
2024-11-15 18:01:14.125|WARN|emoncms_mqtt.php|Connecting to MQTT server: Connection Accepted.: code: 0
2024-11-15 18:04:01.108|WARN|feed_model.php|Feed model: Requested feed does not exist feedid=40

I have looked through previous threads but couldnt see anything that related to this. Any thoughts appreciated.

forgot to add that I changed the antenna to a remote version to improve signal however it the signal had been dropping out with the original antenna.
1696734.pdf (522.6 KB)

That should be more than enough signal. If the emonTHs are not being received by the emonPi2 (and you need to look at the emonhub log to see this), then the question is, is there a local source of interference around the frequency we use (433 MHz) from things like baby alarms, remote doorbells, garage door openers etc, which could be ‘jamming’ the emonTHs?

But given what little I know of MQTT, and from the emoncms log extract, it may well be that the problem is within the Pi itself and the way the data is routed within emonCMS.

If the emonhub log shows a data packet from each emonTH arriving at roughly 55 s intervals, and none missing, you can probably discount radio transmission problems.

Thanks for the reply. Things just got a little interesting. Info was coming through at roughly 60s intervals from the sensors. We have a pair of window blind remotes that work on the same frequency. I tried one for 90s in each direction. Nothing affected, sensor data coming through. I tried the other again 90s each way and this time the countdown counters on the inputs page froze ie wouldnt update for about 15s but have now restarted. The feeds are updating but the emonhub errorlog window is now blank. The errorlog download file is also empty.

I think there’s a good chance that you’ve found the problem. However, while it could be in the radio department, I would have expected both controls to use the same frequency, just a different command inside the message, It seems more likely that the problem might be the motor itself generating interference on the supply, which is making its way into the Pi. If you remove the power from the motor, does the controller on its own still cause the problem?

@TrystanLea What could cause the inputs page update to lock up in this fashion? Would overwhelming emonHub with rubbish data do it, or would it need to temporarily disable the Pi?

Unfortunately the motor units have integral rechargeable batteries so taking them apart wont be easy. On the plus side emonhub log is working again

How do you recharge the battery? If you test again when it’s run down and stopped working…, or if you remove it to charge it, take it away out of radio range and then try the controller?

That it’s just one of the two points to either its location or a difference between the two. OK, they could be working on different frequencies, but I wouldn’t do it that way. Did you have to pair a controller to the motor when they were installed, or something like that? Can you swap them and see if the problem stays with the window or the motor/controller?

(What I’m suggesting is find out if it looks like a faulty unit.)

The motor units have a charge port into which a charger is plugged. Just like a phone which does not have a removable battery.

will try again when it has run down but may be a while.

according to the plate on the back they are both 433.92 MHz

yes they are paired

yes will try that and see what happens.

didnt use the remote blind controllers this evening. communication was lost again around 22:30. the last entry on the error log is at 22:29:53.


how do i upload the log file?

To here? Either with this in the bar above where you type
image
or just drag & drop the file. You should be able to - if you can’t, say so.

Coincidence or is there more than one source to the problem?

I tried that but got a refusal with a message saying it wasnt an authorised extension. Resaved it as .txt.
emonhub(10).txt (4.4 MB)
I have looked through everything else we have but cannot find anything else that might trtansmit on that frequency.

restart emonhub and the feed comes through again and the log screen populates

1 Like

This has to be @TrystanLea’s department. For his benefit, here’s a synopsis;

The file starts at time 21:15:46.
All three emonTH’s are received at approx 58 s intervals until
the last from Node 24: 22:29:18
the last from Node 23: 22:29:26
the last from Node 25: 22:29:53
The file ends at time 22:54:44

1 Like

dropped out again. unfortunately the log doesnt go back far enough but the inputs page lost readings 72 mins ago which would put it at about 22:30 same as yesterday. will restart emonhub and see what happens.

If it happens at the same time tomorrow, it’s too much to be a coincidence. What happens at about time 22:29 ? Maybe not in your house, but a near neighbour’s?

Is there a cron job in your emonPi which runs at about this time?

That’s good to know. Restarting emonHub resets the RFM69 module, it sounds like something is causing the module or code to hang. I will see if I can add a basic watchdog to the EmonHub interfacer that handles communication with the module. We could reset the module periodically if no data is received for say 5 minutes.

@HannoZ I’ve implemented a simple watchdog, that will restart the RFM69 LPL interfacer in emonhub if it does not receive radio data for more than 300s (after having received data previously). Are you able to SSH into the Pi2 and try this branch of emonHub?:

cd /opt/openenergymonitor/emonhub
git pull
git checkout rfm69spi_watchdog
sudo systemctl restart emonhub

Thank you for looking at that. I have implemented the watchdog.

1 Like

Been running with the watchdog for a couple of days. We have lost signal a few times - still dont know where the interference is coming from - but each time the watchdog restarted emonhub. I also increased the feed interval to 10 mins to make sure the feed was ‘uninterrupted’.