On the old forum I asked this question once, but never got things working unfortunately. Now I am revisiting this project and have what might be a simple problem, but has so far proven a problem:
I have 2 pieces of hardware:
first gen Raspberry Pi, running the latest raspbian
the OEM Optical Pulse Counter (OPC)
… and three cables that I need to stick into the gpio pins on my RPi. So far I have the ground and power connected properly, and when holding a blinkenlight under the sensor, the green LED on top blinks in unison. This implies that there also is “something” going over the third little cable, waiting to be listend to.
But, how do I listen to the ttl signal without adding any more hardware in between?
cat /dev/ttyAMA0 whilst ttl cable connected to pin RX, or connected to pin TX, or a generic other GPIO pin
some minicom stuff, but in there, nothing happens.
python script in an attempt to read serial, nothing whatsoever
This leaves me wondering, what exactly is the OPC outputting, and how can I get this output to a commandline using only a Raspberry? I would expect that the OPC would do something such as print(“I saw a pulse”), in whatever form.
… and a quick follow-up: What is the baud rate of the OPC?
You can indeed use the optical pulse counter directly with a Pi.
I use a python script with 2 pulse counters, their data pins are connected to gpio pins 13 and 15, and are powered by pins 9 and 17 so that a simple 1x5 header socket could be plugged directly on the gpio pins (9-17 odds).
Rather than chop the rj45’s off the pulse counters I use a surface mount double rj45 socket with just 4 wires between the sockets and the Pi gpio.
The pulse counters are just a logic level switch, it just translates the light pulses to a distinct on or off signal. there is no baud as such although there is probably a maximum switching speed, but there is very little in the way of info on the shop sold device, We don’t even know what components are used. (hint hint @glyn.hudson can you share some tech info/schematic?)
The python code I use sends an accumulating count for each pulse counter to emonhub via a web socket. It may not suit your needs exactly but should get you started at least, there are notes but do ask if anything is unclear.
I’ve shared all we know! I have tried my best to get the schematic from the factory in China but they won’t share it with us. I did tear down the unit and take some photos of the components inside. Everything we know is documented here: Home | OpenEnergyMonitor
I would love to have full schematics and gerbers, just like I would love the have full schematics showing how an ATmega328, ESP8266 and RFM69CW work
Thanks for the awesome reply guys! I’ve got the OPC working. In sofar that when I hold a blinking light under the sensor, I get a binary blurp on screen (some unintelligible garbage, as if you read serial with the wrong baud rate.) But hey, as the OPC only does that when a pulse is detected, a boolean test works brilliantly.
I’ll make a short write-up including pics when I have the time. Really pulse-detection 101 without anything added.
It sounds like you might have a UART between the you and the sensor, which is probably not what you want for reliable operation. You want to talk directly to the GPIO subsystem which is what Paul’s python code above does.
Looking at it, how are you connecting the Pi and the EmonTX together (directly from the UART)? Is that documented somewhere?
It also strikes me again, that there should be a Wiki that folk can use to contribute solutions and setups for this great community. It is all well and good this being in the forum, but it is difficult to find if you are new in or even if you do a ‘I’m sure I remember’ …
Yes the emonTx 6pin header is connected to the Pi’s GPIO as per the usual “serial-direct” which I believe is documented somewhere in the wiki/site(s), the only real difference being I also connect the emonTx header’s “reset” pin to the Pi’s GPIO18 (pin12) so I can upload sketches to it much the same way we can to the RFM2Pi’s.
I choose to use just the “even” pins 4(5v), 6(gnd), 8(tx), 10(rx) and 12 (GPIO18 “reset”) so a 1x5 way connector could plug on to the Pi’s GPIO alongside the “odd” pins used for the pulse counters as described above.
Just starting a first time install.
I’ve installed emonSD-03May16 onto a pi and got that going along with an optical sensor wired to GPIO and using the script above from @pb66 .
Script worked out of the box alothough I’ve reduced it to one sensor.
I am struggling though to get the data to appear on a node in emoncms.
My emonhob conf contains (as described in the sample py code)
The [[Pulse]] socket interfacer is using the default “ch1” and “ch2” that are not used in the standard OEM settings for the emonpi variant of emonhub. try adding
pubchannels = ToEmonCMS,
to the [[Pulse]] [[[runtimesettings]]] in emonhub.conf, a subchannels setting (currently ch2) is irrelevant as the data for this interfacer will only ever flow one way.
An alternative way of doing it could be to add “ch1” to the [[emoncmsorg]] and/or [[mqtt]] interfacers subchannels setting eg
subchannels = ToEmonCMS, ch1
I only offer this alternative as an insight to how the “channels” are intended to work, the more channels used the more flexibility you have to direct the traffic, with just the one pubchannel “ToEmonCMS” this emonhub version works just like it’s original predecessor in that all traffic gets sent to the same place(s).
I can only advise on how it was intended to work and what I’ve seen on the forum, I do not use this version and my “routing code” was removed and replaced with an external PubSub module after I had written and tested it.
This may also be linked to the previously seen “thread is dead” issues with this variant of emonhub as the “Pulse” thread should not be "Publishing: " that is the job of the MQTT interfacer (see the 4 log entries immediately prior to the first “WARNING MainThread Pulse thread”)
I’m just heading out shortly so I cannot look into it right now. I can try and help you further later on if I get time.
This allows us to determine if the issue occurs whilst doing “MQTT” activities or after it returns to it’s “Pulse” duties. The edits are simple enough to add manually if the PR doesn’t get pulled in.
These log messages are important to the existing “thread is dead” issues as in theory there should be no other logs produced between these 2 messages, by the same thread/interfacer. In practice I’m sure we will see at least the "Publishing: " logs.
It is also useful to your issue regardless of whether the 2 are linked or not as I notice in your original logs that the Pulse thread is returning from "Sending to: " the MQTT as the “Sent to channel’: ch1” log entry is produced afterwards.
however the screenshot shows no such entry despite the logs showing the MQTT was published, which means the thread failed immediately after doing “MQTT” duties or crashed immediately upon return, before writing the log entry.
Could you show me the logs? I’m interested to know if it is one specific channel or any channel that cause it to fail.
thanks. I have put in your changes, here is output.
This is from a running system, I then added the following pubchannels = ToEmonCMS, to [[Pulse]][[[runtimesettings]]]]
and pressed SAVE at about 07:03:35
I then started your pulses.py script at about 07:04:05
As before it does manage to get a single entry into the INPUTs page
2016-11-13 07:02:28,903 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2016-11-13 07:02:57,652 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=&sentat=1479020577
2016-11-13 07:02:58,957 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org
2016-11-13 07:02:58,958 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2016-11-13 07:03:27,702 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=&sentat=1479020607
2016-11-13 07:03:29,002 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org
2016-11-13 07:03:29,003 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2016-11-13 07:03:35,115 DEBUG MainThread MQTT Subscribed to channel' : ToEmonCMS
2016-11-13 07:03:35,116 DEBUG MainThread emoncmsorg Subscribed to channel' : ToEmonCMS
2016-11-13 07:03:35,117 DEBUG MainThread Setting Pulse pubchannels: ['ToEmonCMS']
2016-11-13 07:03:35,118 DEBUG MainThread Interfacer: Subscribed to channel' : ch2
2016-11-13 07:03:57,751 INFO emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=&sentat=1479020637
2016-11-13 07:03:59,038 DEBUG emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org
2016-11-13 07:03:59,039 INFO emoncmsorg sending: https://emoncms.org/myip/set.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y
2016-11-13 07:04:05,562 DEBUG Pulse 1 NEW FRAME : 1479020645.42 18 0
2016-11-13 07:04:05,563 DEBUG Pulse 1 Timestamp : 1479020645.42
2016-11-13 07:04:05,563 DEBUG Pulse 1 From Node : 18
2016-11-13 07:04:05,564 DEBUG Pulse 1 Values : 
2016-11-13 07:04:05,564 DEBUG Pulse 1 Sent to channel(start)' : ToEmonCMS
2016-11-13 07:04:05,565 INFO Pulse Publishing: emon/18/1 0
2016-11-13 07:04:05,567 INFO Pulse Publishing: emon/18/rssi 0
2016-11-13 07:04:05,569 INFO Pulse Publishing: emonhub/rx/18/values 0
2016-11-13 07:04:05,571 INFO Pulse Publishing: emonhub/rx/18/rssi 0
2016-11-13 07:04:05,752 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:05,982 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:06,209 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:06,434 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:06,660 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:06,886 WARNING MainThread Pulse thread is dead
2016-11-13 07:04:07,118 WARNING MainThread Pulse thread is dead````
Okay so that last configuration seems to work ok except for the data not reaching emoncms.org, which would seem correct for the settings as MQTT is configured to listen to both ToEmonCMS and ch1, where as emoncmsorg is configured for just ToEmonCMS and the Pulse data is only going to ch1, correct?
Can you confirm what happens if you then just have “ch1,” without the “ToEmonCMS” for the emoncmsorg subchannels? I assume it will kill the thread based on the previous tests.
As a seperate test from that same “almost working” starting point can you also try adding " pubchannels = ch1, ToEmonCMS " to the Pulse settings? Just to try using 2 seperate channels rather than getting the 2 target interfacers to listen on the same channel.
Perhaps even try these tests again after disabling the RFM2Pi interfacer with a hash in front of the "Type = ",
I will ponder on these logs for a bit and take another look at the code.
Ok so removing the RFM2Pi has no impact, it was a long shot but I just wanted to rule out any “clashing” or conflicts caused by multiple connections, from what read about the pydispatcher module it should work but most users here will only have one channel so it wasn’t proven, but from what I can tell you are not currently using it so I would leave it disabled whilst we debug, it can’t hurt.
My Bad!, Can you remove the “ToEmonCMS” from the MQTT interfacer settings and retry test 3, My intention was to have traffic heading to MQTT on a separate channel to the traffic going to emoncmsorg, but I forgot the MQTT was still listening to “ToEmonCMS” as well, due to there not being any traffic on there during the last test.
So to confirm the RFM2Pi is disabled, Pulse sending to both “ch1” and “ToEmonCMS”, emoncmsorg listening to “ToEmonCMS” and MQTT listening to “ch1”
Hopefully this test will show MQTT successfully publish and then “Sent to channel(start)’ : ToEmonCMS”, if that is not followed by line containing “adding frame to buffer =>” then it would point to the emoncmsorg interfacer causing the Pulse thread to fail. If that is the case we can add a couple of log entries to the emoncmsHTTP interfacer to pinpoint where.
Before adding a load of extra log messages, could you just try adding a second value to your pulse.py? By coincidence I was just about to post a quick comment about a possibility that the emoncmsorg interfacer is not seeing the single value as a “list of one item” and trying to perform an array function (for each in…) might be tripping it up, your new log could support that theory too.