Frustrated


 
Have you posted exactly what version rPi you are running? I couldn't seem to find that info in the thread....
Since you mention v4.2 HM hardware I am guessing perhaps you have an older rPi with a wired LAN? If so, I would connect the wired lan to your network and connect to the HM web interface via wired lan, then login to the HM config and scan for wifi from there. At least that will give you some clue what is going on.
If you don't have wired lan then I would try the AP point SNAPSHOT BUILD and scan for wireless hotspots with a smartphone, connect to HEATERMETER and load the HM web interface from there.
 
Last edited:
Have you posted exactly what version rPi you are running? I couldn't seem to find that info in the thread....
Since you mention v4.2 HM hardware I am guessing perhaps you have an older rPi with a wired LAN? If so, I would connect the wired lan to your network and connect to the HM web interface via wired lan, then login to the HM config and scan for wifi from there. At least that will give you some clue what is going on.
If you don't have wired lan then I would try the AP point SNAPSHOT BUILD and scan for wireless hotspots with a smartphone, connect to HEATERMETER and load the HM web interface from there.

Best I can tell I am running an original raspberry Pi.

I did the whole WPA2 wireless settings and I am 100% thats correct...

I will check out the wired option I can do that pretty easily but didn't know what the benefit was. I didn't know you can scan for networks? Is that a new feature? Maybe its been a while since I have done that.

I will check the config files tomorrow as well.

My level of frustrating isn't reduced unfortunately but I do appreciate all the help.
 
If it just says "Raspberry Pi" I think that means it is an A or B, B with wired LAN and A without...

As far as wired lan, the benefit is that you get your HM working! LOL Connect the rPi wired LAN to network, hopefully DHCP in your router assigns an ip address to the rPi and it is displayed on the HM LCD screen. Connect to that IP address in a browser on a computer connected to the same network and the HM interface will load. From there click CONFIGURATION, once logged in go to NETWORK/WIRELESS and you should see your radio (wireless device) listed there. Click SCAN and it should scan for wifi networks to connect to. Select your wifi and then enter your settings and connect. Once connected to the wifi unplug the lan, reboot the HM and look for the IP address that appears on the screen after it connects to the wifi (watch the wireless device LED for indications of life during this process). If the IP address does not show try going to http://www.heatermeter.com/devices and see if your device and IP are shown there (from a computer on the same network/internet IP as the HM)
 
Last edited:
Working is good!

Its been a long time since I configured my heatermeter. I did back up my old one. Is there a way to restore the alarm settings and email settings or should I just stay away from that old one and hope I set it up correctly this time?

I have thermcouple as probe 0 and I set the low and high alarms and my email address and SMS number so I think I am set.

I did notice I couldn't reach my heatermeter again. I had unplugged it from the lan. I did power up the keyboard and hit enter and THEN I could connect. Is this device falling asleep?

Can I see the IP on the LCD display?

Thanks!

Neil
 
You know what would be cool? To setup a script to SMS me the IP address assigned on start up. Is there a way to do that?

Thanks!

Neil
 
Found the logs. I have these:

Thu Sep 12 21:21:39 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 000100012354f8a0f099b65395ab on wlan0: no addresses available
Thu Sep 12 21:21:47 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00010001250cff88784f43773b35 on wlan0: no addresses available
Thu Sep 12 21:21:58 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00030001c863f1499402 on wlan0: no addresses available
Thu Sep 12 21:22:02 2019 daemon.err uhttpd[348]: wc: /proc/net/nf_conntrack: No such file or directory
Thu Sep 12 21:22:02 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
Thu Sep 12 21:22:07 2019 daemon.err uhttpd[348]: wc: /proc/net/nf_conntrack: No such file or directory
Thu Sep 12 21:22:07 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
Thu Sep 12 21:22:12 2019 daemon.err uhttpd[348]: wc: /proc/net/nf_conntrack: No such file or directory
Thu Sep 12 21:22:12 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key

Any thoughts?
 
Thu Sep 12 21:21:39 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 000100012354f8a0f099b65395ab on wlan0: no addresses available
Thu Sep 12 21:21:47 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00010001250cff88784f43773b35 on wlan0: no addresses available
Thu Sep 12 21:21:58 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00030001c863f1499402 on wlan0: no addresses available

You may have an issue with your DHCP pool.
 
Thu Sep 12 21:21:39 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 000100012354f8a0f099b65395ab on wlan0: no addresses available
Thu Sep 12 21:21:47 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00010001250cff88784f43773b35 on wlan0: no addresses available
Thu Sep 12 21:21:58 2019 daemon.warn odhcpd[293]: DHCPV6 SOLICIT IA_NA from 00030001c863f1499402 on wlan0: no addresses available

You may have an issue with your DHCP pool.

I don't think so. Looks to be IPv6 related. Most people aren't using IPv6.
 
That's the third time I've heard of someone who the autoconfig didn't work, but it worked just fine after selecting it in AP mode from the scan. I'm not sure how that happens, if it is something about the network that gets pulled in from the scan that makes it work or if there's a bug in the autoconfig process that doesn't copy the data correctly. I've tried dozens of combinations, even with a test wifi network to match the SSID/password and it always works here. Glad you were able to work it though though!

The call back to the mothership is solely in place to help people find their HeaterMeters on their network, which is always a problem despite the number of ways HeaterMeter tries to help (SSDP, mDNS/bonjour, the LCD display, the web devices list). The instructions to opt out are on that page Steve linked, and once opted out, the device will fall off the list in 48 hours.

The errors about conntrack are just OpenWrt trying to pull the information to display on the status page in the webui, but because HeaterMeter is not an internet router it doesn't have those features so OpenWrt complains about it. It can be completely ignored and I'm not sure why they decided that's an "error" level severity. I'm not familiar with the IPV6 errors though.
 
That's the third time I've heard of someone who the autoconfig didn't work, but it worked just fine after selecting it in AP mode from the scan. I'm not sure how that happens, if it is something about the network that gets pulled in from the scan that makes it work or if there's a bug in the autoconfig process that doesn't copy the data correctly. I've tried dozens of combinations, even with a test wifi network to match the SSID/password and it always works here. Glad you were able to work it though though!

The call back to the mothership is solely in place to help people find their HeaterMeters on their network, which is always a problem despite the number of ways HeaterMeter tries to help (SSDP, mDNS/bonjour, the LCD display, the web devices list). The instructions to opt out are on that page Steve linked, and once opted out, the device will fall off the list in 48 hours.

The errors about conntrack are just OpenWrt trying to pull the information to display on the status page in the webui, but because HeaterMeter is not an internet router it doesn't have those features so OpenWrt complains about it. It can be completely ignored and I'm not sure why they decided that's an "error" level severity. I'm not familiar with the IPV6 errors though.

Thats fine. The reason I am consulting my logs is because there are times where my heatermeter is not working. Years ago when I first built this heatermeter we discussed that having multiple AP's with the same network name can cause confusion. So I went ahead and installed a luxul network setup. It has multiple access points that appear as one in a mesh configuration. I wonder if this is still a problem. It was such an issue before luxul that I had a dedicated wireless network from ONE AP so there wouldn't be any confusion. I am just still at a loss why the unit is sporadic. Uptime hasn't changed so I don't believe it is a power supply issue at this point. Anything I should check?

Thanks!

Neil
 
So I have left the heatermeter on my desk. Checked it last night and it worked fine. This morning I can't reach network. Here is the logs but there seems to be no information to lend an idea. The 7:25 is when I rebooted....


Thu Sep 12 21:29:30 2019 daemon.info dnsmasq[716]: using 3 more local addresses
Thu Sep 12 21:29:30 2019 daemon.info dnsmasq[716]: read /etc/hosts - 4 addresses
Thu Sep 12 21:29:30 2019 daemon.info dnsmasq[716]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Thu Sep 12 21:29:34 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 0003000194533063c48a on wlan0: no addresses available
Thu Sep 12 21:29:34 2019 daemon.info dnsmasq[716]: read /etc/hosts - 4 addresses
Thu Sep 12 21:29:34 2019 daemon.info dnsmasq[716]: read /tmp/hosts/odhcpd - 0 addresses
Thu Sep 12 21:29:34 2019 daemon.info dnsmasq[716]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Mon Sep 16 07:25:10 2019 user.notice : Time jumped forward by 294940, restarting database
Mon Sep 16 07:25:36 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 0001000124c7abc95cadcfbf9818 on wlan0: no addresses available
Mon Sep 16 07:25:41 2019 daemon.info dnsmasq[716]: read /etc/hosts - 4 addresses
Mon Sep 16 07:25:41 2019 daemon.info dnsmasq[716]: read /tmp/hosts/odhcpd - 0 addresses
Mon Sep 16 07:25:41 2019 daemon.info dnsmasq[716]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Mon Sep 16 07:25:57 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 0001000124a2f519f82d7c0f51da on wlan0: no addresses available
Mon Sep 16 07:26:22 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 0001000120f58fa8f40f2434b9c6 on wlan0: no addresses available
Mon Sep 16 07:26:36 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 000100012409c94bf099b655bf9d on wlan0: no addresses available
Mon Sep 16 07:26:42 2019 daemon.warn odhcpd[294]: DHCPV6 SOLICIT IA_NA from 00030001c863f1499402 on wlan0: no addresses available
Mon Sep 16 07:27:01 2019 daemon.err uhttpd[349]: wc: /proc/net/nf_conntrack: No such file or directory
Mon Sep 16 07:27:01 2019 daemon.err uhttpd[349]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
Mon Sep 16 07:27:28 2019 daemon.err uhttpd[349]: wc: /proc/net/nf_conntrack: No such file or directory
Mon Sep 16 07:27:28 2019 daemon.err uhttpd[349]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
 

 

Back
Top