That is correct, most of the serial-direct implementations on these forums relate to connecting an emonTx (or similar) to the Pi via serial, usually using the Pi’s GPIO. When connecting the serial ports directly the port will usually be ttyAMA0 and when connecting via a USB-serial adapter it will usually be ttyUSB0 etc. Since you are connecting an Arduino device via it’s own USB port it is recognised as a “ACM” (abstract control model), it will work the same way but you just need to use the right address.
Space separated values with a leading node ID is correct, but they do not need to be ints, they can be any datatype or indeed just be normal human readable numbers.
6 123 456.89 0.123 45.6 7.89 0.123456789 1234567890
``
is a totally valid payload.
[quote="kaulquappe, post:1, topic:3822"]
The emonhublog told me that the connection was succesfull with this path. Another good indicator seems to be the error message "Thread is dead" when I unplug the Arduino.
[/quote]
If you have the log level set to "DEBUG" in emonhub.conf you should also get messages showing any received payload progressing through emonhub, including if it fails. If there are no signs of recieved data the probability is it isn't recieving the data.
The serial connection must be exclusive to emonhub, if you have arduino IDE open on that serial port or minicom etc it will be anyones guess who will get the data, but it will only be one SW so ensure the other SW's are not active when testing emonhub.
Your example sketch should also work fine so I would expect there to be much more info available in emonhub.log.
Where is emonCMS? If you are using the emonSD image there is a known issue with the MQTT implementation in emonCMS that prevents new nodes showing up, this can usually be gotten around by rebooting the Pi. This will only work if you are seeing the values being published to emonCMS in the emonhub.log.
EDIT - Also make sure if there is an entry in the [nodes] section of emonhub for the node you are using (ie 6) that it's definition matches the payload you are sending. If sending un-coded values (human-readable) then no decoding is required and `datacode = 0` can be used to specify no decoding (ie zero decoding).
If the definition doesn't fit the data it will discard the data but that will be logged as an error in emonhub.log, if sending data remotely a "suspect" definition can just be removed (commented out) to test but If using the emonSD defining the node is mandatory as emoncms will not work well with numeric node ids or value labels/indexes via MQTT. If using original emonhub the definition is not mandatory.
The first one, is not quite what I need I guess. Read through the threat but found the topics discussed there just partially related to mine.
Second:
log level is DEBUG. No response though.
Serial connection is exclusive to emonHUB, using the Arduino IDE for checking the actual Serial Output was not done simultaniusly. What do you mean by SW’s.
emonCMS is running on a USB-Flashdrive, to prevent the SD-Card from beeing killed. The Usage of the whole System will not create much Data, so USB-Flashdrive will work. Tried rebooting quit often.
I took nodID 6 on purpose, because it expects a Payload of like NodeID val1 val2 val3 val3 val4 val5. 6 is the second of the nodes in the config file. As you pointed out, there should at least be dropped a error message on the log. So i still assume, there is no data coming in at all.
Struggling with your last sentence, because of language and lack of knowledge. From my point of View, without changing the nodees in the config file, the ID 6 should work the way I arranged my datatransmission. Right?
[[6]]
nodename = emontxshield
[[[rx]]]
names = power1, power2, power3, power4, vrms
datacode = h
scales = 1,1,1,1,0.01
units =W,W,W,W,V
No that will not work with your payload (but there should be log messages to that effect) datacode = h says the payload will consist of an unspecified but even number of byte values between 0 and 255, and that each pair of byte values represent a 16bit signed integer. So 5 signed ints would be sent in a payload of 10 byte values.
You are sending full human readable values so no decoding is required. use datacode = 0 for no decoding.
Am I right in assuming you are using the correct address in the conf file as well as the Arduino ID ie
so I tried minicom after rebooting the whole system, but before logging into emonCMS. I assume emonHUB is not up then. minicom is not displaying anything.
BUT the TX-LED is not blinking, as it first starts when emonHUB actually connected to the device. So I assume there is no Data sent.
As I am powering the Arduino with USB and thereby over the Pi, I was actually thinking if the power drain could be a problem. But as far as the System on the Pi runs stable, I didn’t think to deep into that. What are your thoughts on that?
Sorry for disappearing last night, something unexpected cropped up and i had to shoot out.
sudo service emonhub stop
and to start it again afterwards
sudo service emonhub start
I was just saying the emonhub.log you posted was less than 0.25 seconds in length, the fact we see no serial data in the first 0.25 seconds doesn’t prove that the serial isn’t working as even your example only send data every 1 second. That is why I asked if there are any other log messages after a time has passed to confirm.
No that isn’t the case. emonhub starts at boot up and runs independently of emoncms so you would need to stop emonhub and start it again afterwards.
Personally I would not expect a problem powering via the Pi’s USB but I cannot be sure. I would only expect a problem if the Pi’s PSU wasn’t up to powering both the Pi and the Arduino, but in that instance I would also expect the Pi to be struggling too. Do you have another PSU to try?
Do you know how much power the Arduino requires? Upto 500mA should be no problem via a Pi’s USB and there is also a max_usb_current=1 in the /boot/config.txt at the end for allowing upto 1000mA to be drawn from USB if the Pi’s PSU can supply that demand.
It’s a long shot but you could also try using address /dev/ttyS0 just to rule it out.
I don’t know exactly, but I know it won’t be 1000 mA, more around 500mA. PSU of the Pi is capable of 2.1 A. So there shouldn’t be a problem.
Changed it in the config to ttyS0, but then emonHUB doesn’t want to connect. I think we are using the right Port with ACM0. We are just not reading it out.
Before using minicom, I just tried reading out the Port with:
cat /dev/ttyS0
But console stayed empty. (emonHUB was stopped)
I never used minicom before, so I am not sure if I am using it the right way. I was simply doing:
sudo minicom /dev/ttyACM0 9600
But I think this just opens a menu. So I started looking in how to use minicom using this Userguide.According to it I started with dmesg | grep tty what gave me this
So do I, I just thought we could rule it out as I’m not experienced with Arduino’s with on-board USB ie ACM’s.
I’m no minicom expert either as I do not use it often. Ithink the correct syntax might be
sudo minicom -D /dev/ttyACM0 -b 9600
You shouldn’t need to, but until we know what the issue is we cannot be sure.But I wouldn’t start changing anything yet as the emonPi image should be all set to go. What model Pi are you using? and can you confirm if your SDcard is a pre-built purchase, downloaded image or self built image ? Have you updated or changed anything outside what we have discussed here?
sudo minicom -D /dev/ttyACM0 -b 9600 gave me: Device /dev/ttyACM0 is locked.
It’s a Pi3 modelB. It is a downloaded image of the latest version, which I flashed myself. As I want to use it locally, I installed the midori browser and wrote a simple startup script to automatically start the browser with the emoncms GUI:
#!/bin/sh
xset -dpms # disable DPMS (Energy Star) features.
xset s off # disable screen saver
xset s noblank # don't blank the video device
matchbox-window-manager &
midori -e Fullscreen -a http:localhost
I did this before, using the radiomodule for datatransmission, what worked fine. I think at some point I needed to install something like Xorg. Don’t recall it that good, because it was an easy apt-gett install. Then I moved emoncms to the flashdrive.
Could using the other Serialport, that the radiomodule would use, be an option?
Yes it can work but since the serial port is for one-to-one comm it is not wise to allow conflicts to “sort themselves out” especially when debugging. It may have been such a conflict that caused a stray lock file.
I can now see a formatting issue that should look like this
the line ending is missing. Change your test sketch to
const int nodeID = 6;
void setup() {
Serial.begin(9600);
}
void loop() {
int a = 1;
int b = 2;
int c = 3;
int d = 4;
int e = 107;
Serial.print(nodeID); Serial.print(' ');
Serial.print(a); Serial.print(" "); // These for compatibilit$
Serial.print(b); Serial.print(" ");
Serial.print(c); Serial.print(" ");
Serial.print(d); Serial.print(" ");
Serial.print(e); Serial.println();
delay(1000);
}
the println will add the correct line ending and that will also help emonhub as it is waiting for that line ending to signify the end of the payload.
OK, wow this is ridiculous. This was one of the first things I changed in the Code right in the beginning. But as it didn’t solve the problem in the beginning (I think due to the datacode = 0 issue), i thought better moving back to the code in the example file. But the question remains why emonhub didn’t tell something about a wrong format. Right?
Anyway, THANKS A LOT.
PS: Maybe it would be good to change the directserial example in the examplefolder and the documentation of emonHUB. Also it could be pointed out there, that datacode needs to be set to 0. I think it is just talking about choosing the right NodeID.