iserial access and documentation

[dandelot]

The only pdf I can find on iserial is for the v.2 device, and that doc is rather
out of date as I have a new v.4 iserial: the web page served by the device
has lots of things not mentioned for v.2. Is there a more recent pdf?

I'm writing a to iserial using C and watching the Lan
with wireshark. Turned out I forgot to update the
uart data: read() would hang. Having updated
the uart data to the recommended settings
I am getting some data back.

Not getting consistent 255 bytes of data.
Getting "TCP Retransmission" and
"TCP Acked unseen segment" (this as reported
by Wireshark) I better take
another look at the uart settings.

[dandelot]

Uart settings ok, I think. Doing the read repeatedly till all 255
returned is looking ok. Should have thought of that right away.


The write bytes:
Hex ascii. non printable as .
2f3f3030 30333030 30303132 33373030 /?00030000123700
210d0a !..

It is not clear, in what I've found on the developer page,
when any password is needed. Or when 'set meter password'
is relevant and for what.

[Jameson]

Hello,

Sounds like you are making good progress

The meter password is used when you want to make settings to a meter. For a v.4 meter this could be changing CT ratio, controlling the 2 relay outputs, setting the meter password, setting the meter number, setting the meter clock, TOU rates, CF Ratio, resetting Max Demand, setting up the meter so that Max Demand resets on a schedule, etc.

The "Set" commands in this document: http://documents.ekmmetering.com/Omnime ... otocol.pdf will require a password.

The best to see how this works is to use the EKM Dash software. I would use the Hex Inspector and then make settings mentioned above in your meter. The Hex Inspector will show you the sequence and the timing that is needed to make meter settings.

The default password for our meters is "0" (zero). I would leave it at "0" unless there is a compelling reason not to. We have no way of recovering lost meter passwords.

Hope this helps.

[dandelot]

The Dash software gets
App.Event_Open
Delegate.Invoke
Application._CallFunctionWithExceptionHandling
REALbasic._RunFrameworkInitialization

from 'An unhandled NilObjectException has occurred".
Ubuntu 14.04.

So I went directly to writing my own code and watching the
ethernet bytes.

Still ironing out my own bugs. (oops). More shortly.
The water meter just got installed in the ground today.
I'm testing omnimeter and
iserial v.4 without any input pulse commection to the omnimeter.

[dandelot]

Getting a Malformed Packet on the initial byte ( a hex 02 )
of the response to a request type A sometimes. As reported by wireshark.
The byte disappears from what my code sees.

The next frame from wireshark after the 19 bytes
ofa request type A I just sent is:

5 0.009522000 192.168.88.6 192.168.88.2 TCP 179 [TCP Retransmission] 50000 > 40794 [PSH, ACK] Seq=0 Ack=1 Win=1400 Len=125

Frame 5: 179 bytes on wire (1432 bits), 179 bytes captured (1432 bits) on interface 0
Ethernet II, Src: Cimsys_39:4d:33 (00:11:22:39:4d:33), Dst: AsustekC_26:5c:53 (00:23:54:26:5c:53)
Internet Protocol Version 4, Src: 192.168.88.6 (192.168.88.6), Dst: 192.168.88.2 (192.168.88.2)
Transmission Control Protocol, Src Port: 50000 (50000), Dst Port: 40794 (40794), Seq: 0, Ack: 1, Len: 125
Data (125 bytes)

0000 30 30 33 30 30 30 30 31 32 33 37 30 30 30 30 30 0030000123700000
0010 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0020 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0030 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0040 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0050 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
0060 30 30 30 31 32 30 31 30 30 30 30 30 30 30 30 30 0001201000000000
0070 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000
Data: 303033303030303132333730303030303030303030303030...
[Length: 125]

Now this is not really sensible as the leading hex 02 is absent and why the retransmission?

I simply don't see issues like this on the lan except transmission from iserial.
Still, it could by my bug. It would be nice to watch the wire when
Dash was running...if Dash would actually run.

[dandelot]

Adding a sleep(1) between write() and read() has improved things.
Now getting the initial hex 02. !

[dandelot]

Yet another bug in my code trying to help me debug was confusing me.
Now I am seeing correct-seeming response to Request Type A.
Really simple socket coding. But the sleep() requirement was
a small surprise and it was appalling how many mistakes
I made in such a small test application.

So: Now I can read the data properly. Good.

Once I have some real data I'll decide whether to
let a RaspberryPi or another machine do the watching of water use.