search

Shubhamjain007 / openhab

Automatically exported from code.google.com/p/openhab
0 stars 0 forks source link

Enhance SNMP-Binding (Out-Binding) #107

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
1. Feature Description
It would be great if openhab could poll values via snmp from other devices.
Instead of getting snmp-traps.

2. Example Use Case
Gettings temperature values from an OW-SERVER-ENET via SNMP 
(http://www.embeddeddatasystems.com/OW-SERVER-1-Wire-to-Ethernet-Server-Revision
-2_p_152.html)

Or reading values for cpu_load, hdd_temp, free_ram, ... from a server.

Original issue reported on code.google.com by christop...@gmail.com on 23 Aug 2012 at 1:38

GoogleCodeExporter commented 8 years ago 
the underlying snmp4j-lib does support sending requests:

see: http://www.snmp4j.org/doc/org/snmp4j/Snmp.html for more information

Original comment by teichsta on 23 Aug 2012 at 1:42

GoogleCodeExporter commented 8 years ago 
Are there any plans to implement this in the SNMP Binding?

Original comment by bmcro...@gmail.com on 28 Mar 2013 at 10:25

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
no, not yet ... volunteers?

Original comment by teichsta on 16 Jul 2013 at 1:45

GoogleCodeExporter commented 8 years ago 
I just created a separate feature request for the OW-SERVER-binding.
https://code.google.com/p/openhab/issues/detail?id=381

But I think the snmpget/snmpset binding should be more important, because it is 
a widespread standard.

Original comment by christop...@gmail.com on 16 Jul 2013 at 1:52

GoogleCodeExporter commented 8 years ago 
I have this coded and working - needs more testing, but should be available 
soon...
I'm not sure if the OW-SERVER will work though since I'm not sure if the OID 
will remain constant (I have a OW-SERVER so will try and work this out).

Original comment by ch...@cd-jackson.com on 27 Jul 2013 at 11:29

GoogleCodeExporter commented 8 years ago 
Great news!!
I am looking forward to help testing. ;)

Regarding the OW-SERVER:
You are right.
The IDs can change witch each reboot. :(

But it is good to know there is somebody with an OW-SERVER and 
java-developing-skills out there.
It keeps my hopes up. ;D

Original comment by christop...@gmail.com on 27 Jul 2013 at 11:54

GoogleCodeExporter commented 8 years ago 
I should say that I'm a complete noob with openHAB and I'm using this as a 
learning exercise to learn bindings while giving my openHAB install some items 
to play with.

Before I release anything, I should say what I've implemented. This issue 
requests a "OUT Binding". I've implemented this as an IN binding. I could be 
wrong (I'm new to OH) but I think this should be incoming - outgoing would be 
if you wanted to control an SNMP OID.

The implementation is therefore -:
{ snmp="<192.168.2.253:public:.1.3.6.1.2.1.2.2.1.10.10:10000" }

Parameters are -:
*Address
*Community
*OID
*Refresh period

Existing SNMP items would need to be changed to the above format. I thought 
about keeping the existing format, but it seemed a kludge. If you only wanted 
traps, then you set the refresh period to 0.

I may still change the above slightly, and if anyone has any comments, then 
fire away.

Original comment by ch...@cd-jackson.com on 28 Jul 2013 at 9:16

GoogleCodeExporter commented 8 years ago 
This is cool, thanks for working on it! I too am an OpenHAB noob, but being
able to tie network status to OH is great. I am slowly using more and more
SNMP at my place.

Original comment by gee...@gmail.com on 28 Jul 2013 at 9:21

GoogleCodeExporter commented 8 years ago 
Of cause the binding I requested was meant to be an "In-Binding".
I must have confused it, because the SNMP-Traps (wich are already supported) 
are "incomming" and I want to send SNMP-request "out" to the device. :)
Maybe someone can change the subject.

But I think in the long term we need an "Out-Binding" (snmpset) as well.

Maybe you can consider this be changing "{ snmp="<192." to "{ snmpget="<192.".
When someone enhances the binding it is easier to implment the out-binding as 
"snmpset".

Original comment by christop...@gmail.com on 28 Jul 2013 at 10:33

GoogleCodeExporter commented 8 years ago 
I had considered SNMP SET, but not enough to implement it since I don't 
currently have a use case for it (yet).

My concept for the binding was -:
snmp="<192.168.2.253:public:.1.3.6.1.2.1.2.2.1.10.10:10000" for an SNMP GET
snmp="<192.168.2.253:public:.1.3.6.1.2.1.2.2.1.10.10:0" for an SNMP TRAP
snmp=">192.168.2.253:something more here" for an SNMP SET

I hadn't worked out the SET part yet, but I don't think we need an extra 
snmpget (and I don't think the binding system allows more than 1 name within a 
single binding) - just change the direction indicator.

Original comment by ch...@cd-jackson.com on 28 Jul 2013 at 4:53

GoogleCodeExporter commented 8 years ago 
I think that makes sense. :)

Original comment by christop...@gmail.com on 28 Jul 2013 at 5:04

GoogleCodeExporter commented 8 years ago 
Attached is a test version of the updated plugin. Note that this probably only 
works with v1.3 of OpenHAB.
Bindings are as per my previous note -:
snmp="<192.168.2.253:public:.1.3.6.1.2.1.2.2.1.10.10:10000" for an SNMP GET
snmp="<192.168.2.253:public:.1.3.6.1.2.1.2.2.1.10.10:0" for an SNMP TRAP

The configuration in the openhab.cfg file is still the same, and this is still 
used for registing the community for traps (which may need to be updated!). You 
do need to have something in the openhab.cfg file though in order for the 
binding to be run.

Please let me know if there's any problems - especially with TRAPs since my 
devices don't send them. I have tested traps, and it seems to work ok, but as I 
don't have any devices that send traps, I've had to use a program to manually 
send the them. This works, but I'd like to be sure that it still works 
"properly".

Original comment by ch...@cd-jackson.com on 31 Jul 2013 at 8:02

GoogleCodeExporter commented 8 years ago 
Now with the attachment!

Original comment by ch...@cd-jackson.com on 31 Jul 2013 at 8:03

Attachments:

GoogleCodeExporter commented 8 years ago 
Thanks.
I will try this in the next days.

Original comment by christop...@gmail.com on 31 Jul 2013 at 8:17

GoogleCodeExporter commented 8 years ago 
One thing that may need to be added is a check of the incoming address. 
Currently the check is on the OID, but I suspect that if multiple devices send 
the same OID, this would cause a problem resolving the item.

Original comment by ch...@cd-jackson.com on 1 Aug 2013 at 1:28

GoogleCodeExporter commented 8 years ago 
Sorry, but I cannot get it work. :(
Log: http://pastebin.com/MQV7SYXb

openHAB v1.3; Win8 x64; Java7

Items:
Number SNMP_T2 "Temperatur (EDS0065, SNMP) [%.1f °C]" <temperature> (Temp) { 
snmp="<*IP*:*comstring*:.1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1:10000" }

Original comment by christop...@gmail.com on 1 Aug 2013 at 2:06

GoogleCodeExporter commented 8 years ago 
There's an exception thrown the first time the item is updated. I think I know 
why this is (I'd made an assumption that updated gets called before execute, 
but that's not the case here as the listening log entry is after the update 
entry!). I'll fix this.

However, I don't think that this should cause any problem with subsequent 
updates, and the exception is not thrown again. So, it looks to me as though 
there are simply no responses to the request. There should be a "PDU received" 
log entry as soon as the response comes in, so either the request isn't being 
sent, or the SNMP device isn't sending a response.

I'll fix the exception, add a bit more logging and provide an update.

Original comment by ch...@cd-jackson.com on 1 Aug 2013 at 4:05

GoogleCodeExporter commented 8 years ago 
Hey Guys,

Just wanted to say good work on the progress.  I have an SNMP semi-managed
switch which powers my phones.  It is a NetGear GS110TP 8 port PoE switch
for about 115 EUR... other bigger used managed PoE switches can be found on
eBay too... but they consume a lot of power and make a lot of noise.

One of my OpenHAB goals is to be able to check switch port power status, as
well as be able to turn on/off ports.  I am in fact already toggling power
just by using the Linux command snmpset.

I haven't played with the traps, but I guess OpenHAB could be informed when
the switch port power status changes.

I'm currently only using phones, but this same PoE concept would hold true
for PoE surveillance cameras and WiFi APs.  Not that PoE APs would be what
most people would have at home. ;-)

Original comment by gee...@gmail.com on 1 Aug 2013 at 4:39

GoogleCodeExporter commented 8 years ago 
Updated binding with additional logging of outgoing PDU and fix to check SNMP 
object initialised.

Original comment by ch...@cd-jackson.com on 1 Aug 2013 at 4:45

Attachments:

GoogleCodeExporter commented 8 years ago 
New Log:
http://pastebin.com/PWXrvBU2

14:32:26.548 DEBUG o.o.b.s.internal.SnmpBinding[:232]- Item 'SNMP_T2' is about 
to be refreshed now
14:32:26.548 DEBUG o.o.b.s.internal.SnmpBinding[:247]- SMTP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]]

works from another machine:
# snmpwalk -v 2c -c ****** x.x.x.x 1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1
SNMPv2-SMI::enterprises.318.1.1.25.1.2.1.6.1.1 = INTEGER: 22

btw: Did you mean SNMP instead od SMTP? ;)

Original comment by christop...@gmail.com on 2 Aug 2013 at 12:37

GoogleCodeExporter commented 8 years ago 
This again looks fine - yes - the SMPT should be SNMP :) (simple brain fade!).

Based on your binding string, I think you are using the OW-SERVER? I've not 
tried to talk to the OWSERVER with SNMP - can you provide me the full binding. 
You blanked out the community and ip address - I don't need the address 
obviously, but I can't seem to work out the community (at least I can't get the 
OWSERVER to respond). (please email me if you'd prefer - the bit missing at the 
front of my address is chris@cd.....

I can then try and test this with the OWSERVER - maybe there's an issue with 
SNMP version or something.

Original comment by ch...@cd-jackson.com on 2 Aug 2013 at 1:29

GoogleCodeExporter commented 8 years ago 
I am having some trouble with SNMP of my OW-Server. The service stops after a 
few hours and the device needs a reboot. But that's another problem.

So I am using an UPS from APC for this tests, because I now it works. :)
OID = 1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1
Object-Name = uioSensorStatusTemperatureDegC.1.1

The community string just contains a few characters. Nothing special.
But I cannot tell, because the device belongs to my employer. ;)

Number SNMP_T2 "APC UPS Temp [%.1f °C]" <temperature> (Temp) { 
snmp="<x.x.x.x:****:.1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1:10000" }

I will try some more this evening. :)

btw: The community strings for the OW-SERVER are public and private. I think 
you can't even change them.
But like I said. I have some trouble and need to reboot the device sometimes.

Original comment by christop...@gmail.com on 2 Aug 2013 at 7:55

GoogleCodeExporter commented 8 years ago 
Same result for OW-SERVER:

Number SNMP_UPS1 "APC UPS Temp [%.1f °C]" <temperature> (Temp) { 
snmp="<x.x.x.x:*****:.1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1:10000" }
Number SNMP_OW1 "Temperatur [%.1f °C]" <temperature> (Temp) { 
snmp="<x.x.x.x:public:.1.3.6.1.4.1.31440.10.5.1.1.1:10000" }

22:16:31.405 DEBUG o.o.b.s.internal.SnmpBinding[:232]- Item 'SNMP_UPS1' is 
about to be refreshed now
22:16:31.406 DEBUG o.o.b.s.internal.SnmpBinding[:247]- SMTP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]]
22:16:31.407 DEBUG o.o.b.s.internal.SnmpBinding[:232]- Item 'SNMP_OW1' is about 
to be refreshed now
22:16:31.408 DEBUG o.o.b.s.internal.SnmpBinding[:247]- SMTP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]]

BTW:
It looks like the binding stops working after you change something in the 
items-file. :(

22:16:41.414 DEBUG o.o.b.s.internal.SnmpBinding[:232]- Item 'SNMP_OW1' is about 
to be refreshed now
22:16:41.415 DEBUG o.o.b.s.internal.SnmpBinding[:247]- SMTP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]]
22:16:45.036 INFO o.o.m.c.i.f.FolderObserver[:162]- Loading file 'snmp.items'
22:16:45.092 DEBUG o.o.m.i.i.GenericItemProvider[:154]- Read items from model 
'snmp.items'
22:16:45.418 INFO o.o.c.s.AbstractActiveService[:201]- SNMP Refresh Service has 
been shut down
22:18:05.111 INFO o.o.m.c.i.f.FolderObserver[:162]- Loading file 'snmp.sitemap'

Original comment by christop...@gmail.com on 2 Aug 2013 at 8:19

GoogleCodeExporter commented 8 years ago 
I tested the binding and have it working.
i have one problem.

in my test setup i have 2 different snmp machines the got polled however de 
binding mixes things up:
22:48:50.532 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 54
22:48:50.546 INFO  runtime.busevents[:46] - WS2_SNMP_T2 state updated to 54
22:48:50.550 INFO  runtime.busevents[:46] - WS2_SNMP_T3 state updated to 45
22:48:50.554 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 54
22:48:50.570 INFO  runtime.busevents[:46] - WS2_SNMP_T1 state updated to 54
22:48:50.580 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 36
22:48:50.584 INFO  runtime.busevents[:46] - WS2_SNMP_T2 state updated to 36
22:48:50.588 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 41
22:48:50.592 INFO  runtime.busevents[:46] - WS2_SNMP_T1 state updated to 41

It needed to be:

WS1_SNMP_T1 should be 41
WS1_SNMP_T2 should be 36
WS2_SNMP_T1 should be 54
WS2_SNMP_T2 should be 54
WS2_SNMP_T3 should be 45

In my items file i have:
Group       ws1     (All)
Group       ws2     (All)

/* snmpd */
/* Synology ws1 */
Number WS1_SNMP_T1 "Disk 1 [%.1f °C]" <temperature> (temperature,ws1) { 
snmp="<192.168.101.2:public:.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.100.105.115.107.116.
101.109.112.1:60000" }
Number WS1_SNMP_T2 "Disk 2 [%.1f °C]" <temperature> (temperature,ws1) { 
snmp="<192.168.101.2:public:.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.100.105.115.107.116.
101.109.112.2:60000" }

/* Synology ws2 */
Number WS2_SNMP_T1 "Disk 1 [%.1f °C]" <temperature> (temperature,ws2) { 
snmp="<192.168.101.3:public:.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.100.105.115.107.116.
101.109.112.1:60000" }
Number WS2_SNMP_T2 "Disk 2 [%.1f °C]" <temperature> (temperature,ws2) { 
snmp="<192.168.101.3:public:.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.100.105.115.107.116.
101.109.112.2:60000" }
Number WS2_SNMP_T3 "Disk 3 [%.1f °C]" <temperature> (temperature,ws2) { 
snmp="<192.168.101.3:public:.1.3.6.1.4.1.8072.1.3.2.4.1.2.8.100.105.115.107.116.
101.109.112.3:60000" }

Original comment by SJo...@gmail.com on 2 Aug 2013 at 8:52

GoogleCodeExporter commented 8 years ago 
Thanks - at least it works for someone :)
This issue is caused because the binding doesn't correlate the IP addresses. 
This should now be fixed. Please try the attached version.

Original comment by ch...@cd-jackson.com on 2 Aug 2013 at 9:03

Attachments:

GoogleCodeExporter commented 8 years ago 
Thank you! 
i tried it it fixed items with the right temperatures only it has some 
duplicates now:
23:31:24.930 INFO  runtime.busevents[:46] - WS2_SNMP_T2 state updated to 54
23:31:24.935 INFO  runtime.busevents[:46] - WS2_SNMP_T3 state updated to 44
23:31:24.961 INFO  runtime.busevents[:46] - WS2_SNMP_T1 state updated to 55
23:31:26.250 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 34
23:31:26.264 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 39
23:31:26.299 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 34
23:31:26.302 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 39

The problem that christoph faces might have to do that he is using a "Number" 
item on a "String" result:
SNMPv2-SMI::enterprises.318.1.1.25.1.2.1.6.1.1 = INTEGER: 22
the result is "INTEGER: 22"

Original comment by SJo...@gmail.com on 2 Aug 2013 at 9:33

GoogleCodeExporter commented 8 years ago 
Thanks. I'm not 100% sure what you mean about the duplicates. Can you run OH in 
debug and send the log?

Original comment by ch...@cd-jackson.com on 2 Aug 2013 at 9:48

GoogleCodeExporter commented 8 years ago 
by duplicate i ment this:
23:31:26.250 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 34
23:31:26.264 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 39
23:31:26.299 INFO  runtime.busevents[:46] - WS1_SNMP_T2 state updated to 34
23:31:26.302 INFO  runtime.busevents[:46] - WS1_SNMP_T1 state updated to 39

WS1_SNMP_T1 & WS1_SNMP_T2 got polled 2 times while it should be 1 

i have attached the debug log

Original comment by SJo...@gmail.com on 2 Aug 2013 at 10:08

Attachments:

GoogleCodeExporter commented 8 years ago 
So I did some wiresharking. :)

It looks like the snmp-requests and responses are alright.

The OW-Server may be a little problem, because the returned value is an 
OctetString (like "28.1234") instead of an integer.

But the returned value of the UPS is an integer ("21").

Like SJo just found out the snmp-request is send tree times in my case .
I set the interval to 60 seconds, but the requests are send tree times each 
witch 2 seconds delay between them.

I can send you the wireshark-file if that helps, Chris.

Original comment by christop...@gmail.com on 2 Aug 2013 at 10:21

GoogleCodeExporter commented 8 years ago 
I had a look at the log SJo sent regarding the duplicates, and there doesn't 
seem to be anything strange with the binding. It's only showing a single 
request for each Item, but there are two responses.
I have retries set up - but there should be a 1500ms timout, and your responses 
are coming back in less time than this, so (theoretically!) this shouldn't be 
an impact, but maybe it's related? Of course, this probably doesn't explain why 
there would be 3 repeats.
I will make the timeout period, and the number of retries configurable values 
in openhab.cfg so we can turn this off to see if it changes things.

chrisop - I assume that your openhab is still not receiving the requests? If 
it's still not receiving the response in the binding then the wireshark log 
might be interesting.
Regarding the OWServer - I can't get mine to return SNMP requests. I tried 2 
SNMP programs last night without success. I might run up wireshark this morning 
and see what that shows.

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 7:34

GoogleCodeExporter commented 8 years ago 
Actually - retries was set to 2, so that would mean 3 requests in all, so that 
may explain the cause of the repeats, but the time between them from your logs 
doesn't convince me this is the issue. Anyway, retries now defaults to off, so 
let's see if that has an impact.

This version allows you to set the timeout, and the number of retries in the 
openhab.cfg file -:
# The SNMP retry timeout (in ms). Defaults to 1500.
#snmp:timeout=

# The SNMP number of retries. Defaults to 0.
#snmp:retries=0

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 8:19

Attachments:

GoogleCodeExporter commented 8 years ago 
That fixed it!

everything is working perfect now!

Original comment by SJo...@gmail.com on 3 Aug 2013 at 8:48

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I was just about to try something different: see if the firewall might be an 
issue.
But then I realized it started working when I left the computer last night.

12:29:24.984 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:29:24.984 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:29:24.984 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:29:24.985 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:29:24.990 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245154, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1.0 = 27.8125]]' from 'x.x.242.238/161'
12:29:24.991 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.238/161
12:29:25.007 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245153, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = 22]]' from 'x.x.2.38/161'
12:29:25.007 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.2.38/161

I think I found the cause, now.
It's kind of an user error of myself. :(

I had the MIB browser "SnmpB" running all the time and closed it last night.
This program seems to "steal" all incoming snmp-responses.
A soon as I run the application again openHAB cannot get any snmp-responses.

12:42:25.317 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:42:25.317 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:42:25.317 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:42:25.317 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:42:25.321 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245206, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1.0 = 27.8125]]' from 'x.x.242.238/161'
12:42:25.321 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.238/161
12:42:25.340 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245205, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = 22]]' from 'x.x.2.38/161'
12:42:25.340 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.2.38/161
12:43:25.347 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:43:25.347 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:43:25.348 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:43:25.348 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:44:25.384 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:44:25.384 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:44:25.385 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:44:25.385 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:45:25.415 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:45:25.415 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:45:25.416 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:45:25.416 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:46:25.441 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:46:25.441 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:46:25.441 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:46:25.442 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:46:25.446 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245216, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1.0 = 27.8125]]' from 'x.x.242.238/161'
12:46:25.446 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.238/161
12:46:25.465 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245215, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = 22]]' from 'x.x.2.38/161'
12:46:25.465 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.2.38/161

So I guess my issue is fixed. :)
Sorry for the trouble. :(

Original comment by christop...@gmail.com on 3 Aug 2013 at 10:56

GoogleCodeExporter commented 8 years ago 
But there is the the issue that the bindings stops after the item-file is 
changed.

12:51:25.545 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:51:25.545 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:51:25.545 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:51:25.546 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:51:25.549 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245236, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1.0 = 27.8125]]' from 'x.x.242.238/161'
12:51:25.550 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.238/161
12:51:25.569 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245235, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = 22]]' from 'x.x.2.38/161'
12:51:25.569 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.2.38/161
12:51:25.620 DEBUG o.o.m.i.i.GenericItemProvider[:154]- Read items from model 
'snmp.items'
12:51:26.546 INFO o.o.c.s.AbstractActiveService[:201]- SNMP Refresh Service has 
been shut down
12:51:35.629 INFO o.o.m.c.i.f.FolderObserver[:162]- Loading file 'rrd4j.persist'
12:51:35.637 DEBUG o.o.c.p.i.PersistenceManager[:473]- Removed scheduled cron 
job for strategy 'rrd4j.everyMinute'
12:51:35.705 DEBUG o.o.c.p.i.PersistenceManager[:350]- Item group 'snmp' does 
not exist.
12:51:35.711 DEBUG o.o.c.p.i.PersistenceManager[:452]- Scheduled strategy 
rrd4j.everyMinute with cron expression 0 * * * * ?
12:52:00.002 DEBUG o.o.c.p.i.PersistenceManager[:350]- Item group 'snmp' does 
not exist.
12:52:15.718 INFO o.o.m.c.i.f.FolderObserver[:162]- Loading file 'snmp.items'
12:52:15.794 DEBUG o.o.m.i.i.GenericItemProvider[:154]- Read items from model 
'snmp.items'
12:52:15.795 INFO o.o.c.s.AbstractActiveService[:189]- SNMP Refresh Service has 
been started
12:52:15.795 INFO o.o.c.s.AbstractActiveService[:201]- SNMP Refresh Service has 
been shut down
12:52:15.805 INFO o.o.c.s.AbstractActiveService[:189]- SNMP Refresh Service has 
been started
12:52:25.808 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_UPS1' is 
about to be refreshed now
12:52:25.808 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = Null]] x.x.2.38/161
12:52:25.809 DEBUG o.o.b.s.internal.SnmpBinding[:237]- Item 'SNMP_OW1' is about 
to be refreshed now
12:52:25.809 DEBUG o.o.b.s.internal.SnmpBinding[:252]- SNMP: Send PDU 
GET[requestID=0, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1 = Null]] x.x.242.238/161
12:52:25.813 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245240, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.31440.10.5.1.1.1.0 = 27.8125]]' from 'x.x.242.238/161'
12:52:25.813 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.238/161
12:52:25.840 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'RESPONSE[requestID=451245239, errorStatus=Success(0), errorIndex=0, 
VBS[1.3.6.1.4.1.318.1.1.25.1.2.1.6.1.1 = 22]]' from 'x.x.2.38/161'
12:52:25.840 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.2.38/161
12:52:25.972 INFO o.o.m.c.i.f.FolderObserver[:162]- Loading file 'snmp.items'
12:52:25.975 DEBUG o.o.m.i.i.GenericItemProvider[:154]- Read items from model 
'snmp.items'
12:52:26.809 INFO o.o.c.s.AbstractActiveService[:201]- SNMP Refresh Service has 
been shut down
12:53:00.031 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_UPS1' 
with persistence service 'rrd4j' took 30ms
12:53:00.032 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_OW1' with 
persistence service 'rrd4j' took 1ms
12:54:00.004 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_UPS1' 
with persistence service 'rrd4j' took 2ms
12:54:00.005 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_OW1' with 
persistence service 'rrd4j' took 1ms
12:55:00.002 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_UPS1' 
with persistence service 'rrd4j' took 2ms
12:55:00.003 TRACE o.o.c.p.i.PersistItemsJob[:76]- Storing item 'SNMP_OW1' with 
persistence service 'rrd4j' took 1ms

Original comment by christop...@gmail.com on 3 Aug 2013 at 10:57

GoogleCodeExporter commented 8 years ago 
>>But there is the the issue that the bindings stops after the item-file is 
changed.
Yes, I made some changes to fix a couple of issues in this area, but it's still 
an issue. I'm still "evaluating" OpenHAB here, so my config is still not right, 
but I also see this as an issue with other bindings at my end - is it only SNMP 
with your config? I tried debugging this this morning and found after the items 
is changed, the binding doesn't appear to be restarted (is the binding doesn't 
appear to be called from the core). I need to spend some more time on this, but 
the garden beckons.

Looking at your log, there are several "Loading file snmp.items" - some seem to 
work, others don't. Are the ones that work only after OH is started from fresh, 
or does it work some times, and not other?

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 11:39

GoogleCodeExporter commented 8 years ago 
Your binding is the only one that stopped working after items-reload so far.

I don't know why it worked for a short time in the previous log.
But every time I try to reproduce it, the binding stops after the items-reload.

Maybe Kai can help you with this issue.
Especially if this concerns other bindings, too.

Original comment by christop...@gmail.com on 3 Aug 2013 at 3:06

GoogleCodeExporter commented 8 years ago 
Kai has confirmed that this is a general problem with 1.3, since it's happening 
with other bindings as well (and for other people).

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 3:17

GoogleCodeExporter commented 8 years ago 
I just tested the trap-function.
(The UPS-Webinterface has a button to send a test-trap)

The Log shows the trap arrives. ;)
18:23:53.889 DEBUG o.o.b.s.internal.SnmpBinding[:178]- Received PDU 
'V1TRAP[reqestID=0,timestamp=18:16:37.10,enterprise=1.3.6.1.4.1.318,genericTrap=
6,specificTrap=636, VBS[1.3.6.1.2.1.1.3.0 = 18:16:37.10; 1.3.6.1.6.3.1.1.4.1.0 
= 1.3.6.1.4.1.318.0.636]]' from 'x.x.242.171/46762'

But to be honest I don't know, how to use this.

Is this item-config right?
  String SNMP_Trap1 "Trap: [%s]" <temperature>  { snmp="<x.x.242.171:public:.1.3.6.1.6.3.1.1.4.1.0:0" }

Aside from that I get these messages right after the trap comes in.

18:23:53.891 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.2.38/161 x.x.242.171/46762
18:23:53.892 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.171/161 x.x.242.171/46762
18:23:53.893 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent 
x.x.242.238/161 x.x.242.171/46762

What does "Address inconsistent" mean?

btw: I think it would be better to display the ports with a colon 
(x.x.242.238:161)
Otherwise you get confused with the subnet-syntax (192.168.1.0/24).

Original comment by christop...@gmail.com on 3 Aug 2013 at 4:29

GoogleCodeExporter commented 8 years ago 
To be honest, I'm also not sure about traps. I've tested the functionality 
using a program I found on the web (SnmpTrapGen), but I wasn't really sure what 
the different parameters in the trap are and I don't have anything that 
generates a real trap. I'll have a read up about this and see if I can work out 
how it works.

>What does "Address inconsistent" mean?
It just means that it's checking the addresses as it loops through the items 
trying to find the right one with the right address and right id. It's a debug 
message while I was adding the address check and I'll remove it now.

>btw: I think it would be better to display the ports with a colon
I would agree, but apparently Java doesn't! I'm using a standard Java function 
to display the addresses. Java also expects the address to be passed in this 
format, so when I create the items in the binding, I also need to add the /161 
to the end of the IP addresses...

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 4:53

GoogleCodeExporter commented 8 years ago 
Ok.

So I guess this means, there is something wrong.
   18:23:53.892 DEBUG o.o.b.s.internal.SnmpBinding[:183]- Address inconsistent x.x.242.171/161 x.x.242.171/46762

This should match, but apparently doesn't.
"x.x.242.171/46762" seems to be the adress of the trap.
"/46762" is the source-port of the trap-package and veries everytime. (just 
tried with wireshark)
"/162" would be the default destination-port of a trap-package.

btw: Despite the issues I list here: GREAT WORK!! ;)

Original comment by christop...@gmail.com on 3 Aug 2013 at 6:54

GoogleCodeExporter commented 8 years ago 
Good point - there's nothing to say that traps have to come from port 161 or 
162. I'll change the address check to ignore the port - that ought to fix this 
one :)
It'll probably be tomorrow for the fixed version.

Original comment by ch...@cd-jackson.com on 3 Aug 2013 at 7:17

GoogleCodeExporter commented 8 years ago 
This version adds an address translation for TRAPs. It changes the port number 
from the incoming address to port 161 to allow it to pass the address checks 
when processing the PDU.
I've left the "address inconsistent" message in for now so we can check this is 
all working since I can only partly test change.

Original comment by ch...@cd-jackson.com on 4 Aug 2013 at 8:59

Attachments:

GoogleCodeExporter commented 8 years ago 
> Your binding is the only one that stopped working after items-reload so far.

This should be fixed with my latest changeset!

Original comment by kai.openhab on 4 Aug 2013 at 9:26

GoogleCodeExporter commented 8 years ago 
Trap workes.
The trap is received and the OID "1.3.6.1.4.1.318.0.636" is stored as a string 
in the item.
This OID can be translated as "PowerNet-MIB::apcTestTrap".
Id the UPS loses the power input for example it would be another OID.

So you can create rules like:

  when
    Item SNMP_trap1 changed to '1.3.6.1.4.1.318.0.636'
  then 
    sendMail"Test-Trap received")

Feature request:
It would be really great if the binding could use MIBs to translate OIDs.
But that's just "nice to have". ;D

Original comment by christop...@gmail.com on 4 Aug 2013 at 10:54

GoogleCodeExporter commented 8 years ago 
Perfect - thanks for testing this out.  I'll tidy a few things up (remove some 
debug messages) and push a final version.

I've also tested Kais latest changes, and the binding seems to start up ok now 
after the items have changed.

I think that the library to read the MIB is only available under a commercial 
license - I'll double check that, but I think that's the case so it's not 
possible to support that (unless I can find another library).

Original comment by ch...@cd-jackson.com on 4 Aug 2013 at 11:32

GoogleCodeExporter commented 8 years ago 
btw: Will this binding replace the existing snmp-binding? Will it be in v1.3?

In this case we need to think about users who might already using the previous 
binding.
Their configs might not work after updating to the new binding.

Otherwise we might want to rename this to avoid confusion about the two "snmp 
bindings".

Original comment by christop...@gmail.com on 7 Aug 2013 at 6:36