I am trying to install Emonhub on a NUC intel mini PC running Debian Jessie.
I have been following these instructions( GitHub - openenergymonitor/emonhub: Python service linking and decoding input to MQTT & Emoncms ) but the installation fails because the file structure of my system is different from a Pi.
After some tweaking I manage to get the emonhub running and posting to MQTT. However the Emoncms MQTT Input Service is not running. Hence no input are appearing.
Data is sent to the PC via USB by an emontx shield mounted on an arduino. I can see data being posted to emonhub.
Any idea how I can fix the issue of Emoncms MQTT Input Service not running ?
Is there a “proper” instruction to install correctly emonhub on a PC rather than a PI ?
I have installed Emoncms using this method: emoncms/LinuxInstall.md at master · emoncms/emoncms · GitHub
I think Emoncms is working fine. If I send data trough http I can see the feeds appearing into Emoncms
The problem is with emonhub. The tutorial I used is for a pi board and not a PC.
In the emonhub config file, you should find an HTTP interfacer that uses the HTTP interface to send data to emoncms.org. If you change that host to your local IP address, and add in the API key, it should work (or if you use an emoncms.org account - copy the interface definition).
Sorry for the very, very late reply (holiday time here in France)
Thanks for pointing this “solution”. It works. I can use the HTTP interfacer (limited a max rate of every 30s, though) to post to my local machine. This is a good temporary solution.
However it would be nice to have a proper emoncms installer for a linux distro on a PC and not only for a PI.
The reason I use a real PC and not a PI is due to SD card corruption. I have never managed to get Emoncms running on a PI more than 6 months in a row
The main power supply where I live (in the woods) is really bad with frequent cut off. That may be an explanation. BUT I never have any problem with my 3 linux PC.
There may be a misunderstanding here - Emonhub is an interface that (largely) takes data from a serial interface (such as the RFM69Pi) and passes that data on to EmonCMS. It passes data in a number of ways but the most common is via an MQTT Broker or HTTP.
What are you expecting Emonhub to do for you?
Where is the data coming from?
Does this mean you have Emonhub installed and running but the MQTT part of Emoncms is not working? I’m not certain that the HTTP interface is limited to 10s.
It is hoped the scripts will eventually do that to some extent, but as the user base is predominately Pi based, that is always going to be the focus. I run the RFM board and Emonhub on an OrangePi using the HTTP interface. My Emoncms setup is on DietPi on a VM. However, my MQTT broker runs on a different machine. Most complexities can be worked through.
The 30s sendinterval can be defined in the interfacer runtimesettings
That setting was designed to reduce traffic to emoncms.org, instead of emonhub sending multiple 10s payloads, it could send all of them in one payload once every 10s, but the default has become 30s. Just reduce it to 10s if you have multiple 10s devices or lower for a less “batched” operation, this setting only throttles the sending so (for example) if you have a 10s device and a sendinterval of 5s, it will still be sent instantaneously as it will always be over 5s since the last send.
The HTTP method is superior to the MQTT method, even on an emonSD. There is no need for this to be a temporary solution, even if you get MQTT fully functioning, I’d recommend staying with the http interfacer to pass data between emonhub and emoncms.
Using HTTP doesn’t mean you cannot still use MQTT to let other devices get at the data, but it does mean theat the most important audience (emoncms) is getting better quality data from emonhub.
So your data is “grouped” into payloads, when this is passed by MQTT it is split into individual topics without timestamps rather than passed as a single array with a timestamp as the http interfacer does. This means that the order of the values can alter between emonhub and emoncms, which can play havoc with your input processing if you reference inputs from any input.
You can add a spinnimng disk hdd to a Pi or make the OS read only and just put your data files on a USB stick.
A simple little 12v battery and mains charger, supplying the Pi via a 3A 12v-5v micro-usb dropper would prevent any power interruptions. I also put my router on the UPS so micro-outages do not trigger a router restart and the usual eternal delay before it’s fully back on line (my router is 12vdc, but that varies model by model).
The biggest cause of premature SDcard fails is incomplete writes due to the power failing (or the card being removed) during a write cycle. To prevent failing the card this way either don’t write (RO OS) or don’t lose power (UPS), it’s the only safe way to use an sdcard.
And we should indeed be encouraging the re-purposing of of old tech rather than just promoting the latest model Pi. If the PC works for you then that is great.
There is work in the pipeline to make the OEM and emon stuff less (emon)Pi centric but it will take some time. The new installer should be hardware agnostic, providing the OS distro is supported, it should work fine and just leave out the more Pi centric bits like the LCD and serial port stuff.
I know all this workaround but by the time you did all of this and bought all the necessary the parts a second hand mini PC like a NUC is far cheaper, already package neatly and ready to go. It uses only 3W running. Quiet acceptable
The lowest price I can find for a NUC is 75 USD. (+ 8 USD shipping)
(Do you know of a source that sells them for less than 75 USD?)
If one already has a RPi, then adding an external disk drive to it can be done at reasonable cost.
A 16GB SSD can be had for as little as 6 USD
and a SATA to USB cable is also available for 6 USD.
(Note, the SSD is not new. i.e. it’s used, but at 6 bucks a pop, one could
buy a spare and still not spend a lot of money)
Granted a complete NUC is an all-in-one unit, in a nice compact package, and the SSD/USB
cable add-ons are not, they’re still very affordable at a total cost of 12 USD.
If I change the value to 10s I still get data in Emoncms every 30s
Emoncm is running on the same machine as Emonhub.
Data is sent from an arduino with a emontx shield running a serial_direct sketch . Arduino is connected to PC via USB.
64 bucks with shipping, so still a bit more than adding an SSD and SATA-to-USB cable.
But, not a bad price for a NUC, considering I’ve seen them listed for much more than 50 bucks!
(not to mention more computational “horsepower” than a RasPi as well)
Ahh! The penny just dropped, that should be interval = 10 not “sendinterval”. This has come up before, there is some confusion around that setting as it was originally “interval” but got changed at some point to sendinterval in the emon-pi variant, and then back again at a later date. The file I looked at on GitHub is a “default” conf that hasn’t been corrected, the actual conf file is correct
One last question: my emonhub.conf file is in /etc/emonhub
however the emonhub module is looking for it in /home/pi/data
therefore I cannot modify the emonhub.conf file directly in the web interface by clicking the “edit config” button.
How can I explain to the emonhub module editor that it should be looking for the file in /etc/emonhub ?
Good question, however the emoncms/config module is hardcoded to /home/pi/data
So you can either edit the php code directly, but that will block you from pulling in future updates without saving/losing those changes and reapplying them afterwards. Or you can just accommodate the hardcoded path by creating a symlink at /home/pi/data/emonhub.conf pointing to /etc/emonhub/emonhub.conf so that the config module can find the same conf file at the path it expects.
These are the sort of things i hope get resolved with the new installer. But by rights as I keep saying time and time again. If they had hardcoded a path to /etc/emonhub and then when the file is located elsewhere (eg /home/pi/data on emonSD) add a symlink to that other place. that would mean the conf file is always found in /etc/emonhub on all setups regardless of where it actually is…
[edit] Or I suppose you could actually move the emonhub.conf to the /home/pi/data path but that just seems odd! Having a symlink at that path when you have no user pi, is reasonably obvious it is a “workaround” whilst having the conf file on that path just isn’t right in my mind.
