HeaterMeter Config Error


 
A

AKvaternik

New member
HeaterMeter Unknow Error - "error on line 56 at column 43: Input is not proper UTF-8"

Hello All - I was loading the latest HM image and after I was done, I got this error on the config screen - "error on line 56 at column 43: Input is not proper UTF-8, indicate encoding". I tried a previous image from last March and got the same thing.

I'm stuck as I can't configure any probes, etc. Any suggestions.
https://photos.app.goo.gl/xQNZmQh4XBh2rx953

Thanks.

Agglomerator
 
Last edited:
Well that is interesting. Try doing a "View Page Source" in your browser, and there is probably an error message in the middle of the source that's causing it to fail to render at all.
 
Ah looks like the probe names seem to be a buncha weird characters? What are the names of the probes on the regular webui home page (the graph one)?

You might be able to fix just that by going to System -> Startup and setting this as the "Local Startup" script then doing a Submit and rebooting.
Code: 
lmclient LMST,pn1,probe
lmclient LMST,pn2,probe
exit 0

That will reset food1 and food2 probes to be named "probe", so once it has been fixed you'll want to take that back out and make the script just "exit 0". If that fails, you can reset everything back to default by using the menus on the device itself and going to "Reset Config?" and saying yes.
 
Hello Bryan - thanks for the troubleshooting tips. Adding the script didn't fix it, but doing the "Reset Config?" step did fix the problem. Thank you so much!

Random question - is there a way to save off my Linkmeter config so that I can restore it if needed? Is that what the "System>Backup/Flash Firmware>Generate Archive" does?

Thanks again.

Andre Kvaternik
 
Yeah that will save all the data stored on the Pi, such as the network configuration and all the SMS/Email alert config. The HeaterMeter configuration like the probe types and PID settings are only stored in the EEPROM on the ATmega so there's not really a good way to back that up :/
 
Bryan Mayland said:
Yeah that will save all the data stored on the Pi, such as the network configuration and all the SMS/Email alert config. The HeaterMeter configuration like the probe types and PID settings are only stored in the EEPROM on the ATmega so there's not really a good way to back that up :/
Click to expand...

That data is easily backed up by saving the "Full configuration URL" info at the bottom of the config screen. Anytime I'm adjusting parameters I copy that info to a text file so I can restore things back to a known good state if things get messed up.
 
I was going to mention that, but v14 is the last version where that is guaranteed to work because the GET method is a big security risk. I haven't worked out what the replacement is going to be yet though.
 
Bryan Mayland said:
I was going to mention that, but v14 is the last version where that is guaranteed to work because the GET method is a big security risk. I haven't worked out what the replacement is going to be yet though.
Click to expand...

This is primarily insecure due to the nature of accessing the HM over cleartext HTTP, rather than encrypted HTTPS. I'd love to see the HM webUI strive towards an HTTPS only approach. The process of generating and installing an SSL cert is becoming easier every day, or even just using a self signed cert is upping your level of security when compared to using plain old HTTP.
 
Steve_M said:
This is primarily insecure due to the nature of accessing the HM over cleartext HTTP, rather than encrypted HTTPS. I'd love to see the HM webUI strive towards an HTTPS only approach. The process of generating and installing an SSL cert is becoming easier every day, or even just using a self signed cert is upping your level of security when compared to using plain old HTTP.
Click to expand...
HTTPS GET is absolutely not any more secure than HTTP GET. Encrypting the connection does nothing for API security apart from preventing people from snooping it. Me adding a img to this post with the image URL https://heatermeter.local/luci/lm/set?sp=999 will change your HeaterMeter's setpoint regardless of if it is HTTP or HTTPS. HTTPS for devices is a pipe dream, my friend. A good number of users can't even find the HeaterMeter on their network, much less connect by name, which you'd need for an HTTPS cert to work.

The webui will go toward cloud-based HTTPS connections, not toward direct device connections with self-signed certs or continuously updating letsencrypt certs which only work with FQDNs.
 
Bryan Mayland said:
HTTPS GET is absolutely not any more secure than HTTP GET. Encrypting the connection does nothing for API security apart from preventing people from snooping it. Me adding a img to this post with the image URL https://heatermeter.local/luci/lm/set?sp=999 will change your HeaterMeter's setpoint regardless of if it is HTTP or HTTPS. HTTPS for devices is a pipe dream, my friend. A good number of users can't even find the HeaterMeter on their network, much less connect by name, which you'd need for an HTTPS cert to work.

The webui will go toward cloud-based HTTPS connections, not toward direct device connections with self-signed certs or continuously updating letsencrypt certs which only work with FQDNs.
Click to expand...

Good point. I wasn't considering the malicious link type of attack as you pointed out. That's definitely a problem if there's no other auth mechanism such as using an API key in a header. Could the "Raw set command" input box be used for something like this? Change the method to POST and then have the user paste in the config settings?

I don't think https for devices is too big of a pipe dream, but cloud/reverse proxy https connection is definitely going to make things easier on the end user as it will also eliminate the need for figuring out port forwarding, etc. In my mind I was thinking something like this.

- heatermeter boots up and sends device info to heatermeter.com ( currently does this )
- heatermeter.com has service running that can generate & renew a cert for $HMSERIAL.myheatermeter.com
- heatermeter.com can also update DDNS entry of $HMSERIAL.myheatermeter.com to the requesting IP
- heatermeter checks its local cert to see if it has a valid cert for $HMSERIAL.myheatermeter.com. If not, downloads the cert from heatermeter.com and installs it

I realize this has its own problems that could allow someone else to request the cert for $HMSERIAL.myheatermeter.com and change the DDNS IP. This is all very "shower thoughts" type of brainstorming on my end.
 
Yeah I think you're on the right track there. I have software design plans to have the ability to stream per second updates to a cloud server which then fully duplicates the local interface on a internet-accessible https site. It would require a user account to be able to claim an unregistered device (from your same IP) and be able to control it, which you could then keep private, make public (anyone with link) or publish (shows up on the heatermeter.com page for everyone). The website also stores HeaterMeter device configurations with tags and checkpoints so you can undo changes or reset to your own defaults and stuff pretty easily. I don't see any reason the local device can't also have some better ways of being able to import/save settings apart from the configurl though.

In addition to being able to bounce to your registered device by public IP, you can also register a $YOURID.smoky.link DDNS entry which points to your public IP. A certificate will also be kept updated on the local device as part of the DDNS update procedure. Unfortunately for the tech-non-savvy this still requires a hole in the firewall and a port forward. I expect it would be more useful to advanced users who prefer their privacy and want to connect to their device directly. The tunneled data and storage on the main website would be for the majority of users.

I had in my design that it would a a certificate signed by me as the CA but now that you've brought it up... is it within letsencrypt's rules to proxy generation of certificates for client devices? I think that would be ideal because my idea was kindof crap because the user would have to import me into their CA list which is somewhat of a non-starter. Your idea is much better if that's what you're suggesting.
 
Bryan Mayland said:
I had in my design that it would a a certificate signed by me as the CA but now that you've brought it up... is it within letsencrypt's rules to proxy generation of certificates for client devices? I think that would be ideal because my idea was kindof crap because the user would have to import me into their CA list which is somewhat of a non-starter. Your idea is much better if that's what you're suggesting.
Click to expand...

Yep, you can proxy letsencrypt requests. This is easy to do using the DNS-01 challenge where you simply need to generate a TXT record for each A record. The only problem you may run into is with the current rate limits of LE of a max of 20 per week per domain. This won't affect renewals, just initial registrations of new entries.
 
Let's Encrypt just announced that ACME v2 and Wildcard Certificate Support is Live

Pros: delivering certs to any number of devices will be greatly simplified

Cons: wildcard certs means same key + cert needs to be installed on all devices. Basically need a "devices only" domain name and another domain for all other purposes. ie smoky.link and heatermeter.com
 
I just finished getting the wildcard stuff working on my own domains and learned something new. You can have *.subdomain.domain, which I didn't think was possible. So you could have a wildcard for *.hm. smoky.link and distribute that key + cert to all the devices. The nice thing about this, is if if you wanted to generate certs for things like www.smoky.link, it wouldn't be using the same key and cert as *.hm. smoky.link.
 
You must log in or register to reply here.

 

Back
Top