Simple Network Management Protocol would win you a boatload of users. I have several remote solar sites and being able to track battery state etc would be fantastic, without having to have the 'local app' running.
Hi Rockhead.
We are looking into SNMP for the Classic. It will take some time and some work
but would still be advantageous.
The reason to need it of course is that the software that those industries are using
that use SNMP to query connected devices, do not have modbus over tcp/ip upgrades.
It is actually much easier to change their software on the host PC rather than inside
an embedded device like the Classic but if that's what is needed, I guess we have
to look into doing SNMP closer.
What software is it that you are using on the PC side ?
The problem at the moment is resources and time (same thing ?)
Thanks for the input !
boB
Its always about resources isn't it :'( . I currently have Cacti http://www.cacti.net/ (http://www.cacti.net/) running a few Ubuntu Linux boxes. The need for network monitoring of remote sites has been discussed greatly over at the Ubiquiti forum, everything from existing hardware to proposed roll your own solutions http://community.ubnt.com/t5/Business-Talk/IP-based-solar-charge-monitor/m-p/105581#M5151 (http://community.ubnt.com/t5/Business-Talk/IP-based-solar-charge-monitor/m-p/105581#M5151)
I suppose the key question for me is if I can get any sort of continuous monitoring and
ideally get an alert
alert alert alert danger Will Robinson
emailed/texted when the sh1t is less than six inches from the fan .
Quote from: rockhead on June 09, 2013, 02:58:34 PM
I suppose the key question for me is if I can get any sort of continuous monitoring and ideally get an alert alert alert alert danger Will Robinson
emailed/texted when the sh1t is less than six inches from the fan .
RossW has been working on an application that continuously monitors the Classic modbus registers via ethernet and could probably easily be used to trigger events based on register values from the Classic. been running it here awhile on a Raspberry Pi. It is stand alone on a local system so you can massage the output to do pretty much anything with common Unix / Linux tools. I didn't try to relocate the thread but it is here on the forum someplace.
Just tossing that out.
Tom
I can pass on a binary for Either a Pi with Raspbian or a PC with Ubuntu 11.10 and Ross probably can provide one for OSX. Not sure if anyone is using it on Windows.
Just let me know.
Tom
Ubuntu linux would be good :D I've been reading the 'blackbox' thread and he's got some nice looking graphs on his link, either rrdtool or cacti I'm guessing, it would be interesting to hear how that gets tied in.
Quote from: rockhead on June 09, 2013, 04:34:37 PM
Ubuntu linux would be good :D I've been reading the 'blackbox' thread and he's got some nice looking graphs on his link, either rrdtool or cacti I'm guessing, it would be interesting to hear how that gets tied in.
Yep, rrdtool.
Message me your email and I will fire off a copy I compiled on Ubuntu this morning.
Tom
Quote from: rockhead on June 09, 2013, 04:34:37 PM
Ubuntu linux would be good :D I've been reading the 'blackbox' thread and he's got some nice looking graphs on his link, either rrdtool or cacti I'm guessing, it would be interesting to hear how that gets tied in.
Rundown on what I'm doing.
My code is written in C and contains everything it needs to run. No modbus libraries need to be installed or linked, I wrote my own.
The code has a number of operating modes, by default it just spits the data you asked for to stdout and then exits. The -c switch (continuous) loops forever spitting out that data every second. Either way, you can manipulate however you want as Tom already said.
In continuous mode, it will (by default) open a connection to the classic and leave it open. The -r (reopen) switch tells it to close the connection as soon as it's read the data, and re-open it for the next read. This will let it co-operate with other modbus applications that want to talk to the classic.
Another switch -w will write data for logging - currently thats only to one of my servers because we're still playing with this thing and working out what we want it to do. It sends a single http request to my server with about a 14 registers for graphing. It will send this packet once per execution in single-pass mode, or once every 5 minutes in continuous mode.
At the logging and graphing end, I wrote a simple system to take arbitary data from almost any source and graph it using my own front end to rrdtool. Graphs are either created as static images (graphs accessed frequently) or on-the-fly (for ones that are not accessed so often)
Yesterday, with some help from Bob in IRC, I came to understand the logic behind the time-set code, and now the -t flag will set the classic date/time from the system time (which should be using ntp, right??). That works fine - only the time keeps resetting back to what it was... and have identified that setting the classic datetime isn't much use if you have time-sync on in tweeks (as the mngp keeps overwriting it!). It'd be nice to be able to set the mngp clock the same way but aparantly that isn't currently possible.
Tom and I are playing with the code. (Let me clarify that... Tom makes suggestions of what he'd like to see it do, and I turn out some code as I get time and bounce it to him). Happy to take feature requests though.
What else can I tell you??
I just installed my Classic 150 so I haven't got a lot of questions, yet :o. I am curious about the focus on time setting, does the built in clock drift badly or ???
Perhaps the continuous mode could have a switch for interval sleep(15) sleep(30) etc .
Thanks for your contribution !
Quote from: rockhead on June 09, 2013, 05:57:32 PM
I am curious about the focus on time setting, does the built in clock drift badly or ???
Mine hasn't been a problem. One of TomW's appeared to get out of whack pretty quickly.
Time set is in fact really an "enabling technology". Once I get that, I've basically got the groundwork done for sending other things - like wind curves etc.
Quote
Perhaps the continuous mode could have a switch for interval sleep(15) sleep(30) etc .
Code is already basically done, just didn't want to complicate things before there was a need/interest/request :)
The background behind this was to come up with a small external box that just "plugged in" and gave you a convenient web interface to do things with. Sort of like a "local-app + mymidnite" on steroids, in a box...
Quote
Perhaps the continuous mode could have a switch for interval sleep(15) sleep(30) etc .
Code is already basically done, just didn't want to complicate things before there was a need/interest/request :)
The background behind this was to come up with a small external box that just "plugged in" and gave you a convenient web interface to do things with. Sort of like a "local-app + mymidnite" on steroids, in a box...
[/quote]
Cool ! Suggestion, skip the box, stash it in a cloud, charge a small fee, put your feet up, LOL.
Quote from: rockhead on June 09, 2013, 10:28:57 PM
Cool ! Suggestion, skip the box, stash it in a cloud, charge a small fee, put your feet up, LOL.
I am sure it could be done.
My original idea was something you do not even need the external internet itself to use.
All I was looking to come up with was a local method that skipped the middleman and gave me info on my internal LAN in the beginning. Of course it has grown beyond that and has a life of its own now. I probably have all I need in it now but it is Ross's baby.
I am limited to crappy internet unless I go for satellite and then I hear its not "good" so I prefer things I can use locally. Being retired I don't travel much so my needs do not require external access and if they did my internet would likely be down when I did need it.
Out of my hands now. Ross will have it sending texts to your cell before long.
Its all good, however.
Tom
Quote from: rockhead on June 09, 2013, 10:28:57 PM
Cool ! Suggestion, skip the box, stash it in a cloud, charge a small fee, put your feet up, LOL.
The problems with that are that I have no way to make the classic send the data to some arbitary server, somewhere.
The only way past that is to have the server go and poll your classic for it...
... and the problem with THAT is that it will need people to come up with some way for my code to access their classic from outside. Dynamic DNS, flakey connections, NAT in routers, port-forwarding.... its fine for those of us who do it all day, but it's a big ask expecting people to do that with their unknown routers.
The other big risk with it is exposing your midnite to "the internet". The potential for someone outside to mess with your classic is non-trivial... and not something I'd be willing to do without a great deal of care.
Quote from: RossW on June 09, 2013, 11:42:27 PM
Quote from: rockhead on June 09, 2013, 10:28:57 PM
Cool ! Suggestion, skip the box, stash it in a cloud, charge a small fee, put your feet up, LOL.
The problems with that are that I have no way to make the classic send the data to some arbitary server, somewhere.
The only way past that is to have the server go and poll your classic for it...
..and that is why I was asking for a firmware update to have modbus registers with a destination IP number that if specified would be used instead of the MyMidnite server. Also encrytion dropped.
That way a local or WAN server could receive and process Classic data.
dgd
Quote from: RossW on June 09, 2013, 11:42:27 PM
Quote from: rockhead on June 09, 2013, 10:28:57 PM
Cool ! Suggestion, skip the box, stash it in a cloud, charge a small fee, put your feet up, LOL.
The problems with that are that I have no way to make the classic send the data to some arbitary server, somewhere.
The only way past that is to have the server go and poll your classic for it...
... and the problem with THAT is that it will need people to come up with some way for my code to access their classic from outside. Dynamic DNS, flakey connections, NAT in routers, port-forwarding.... its fine for those of us who do it all day, but it's a big ask expecting people to do that with their unknown routers.
The other big risk with it is exposing your midnite to "the internet". The potential for someone outside to mess with your classic is non-trivial... and not something I'd be willing to do without a great deal of care.
Oh sure, ruin a good idea with careful consideration LOL.
I do know that Andrew plans to have data available for people on my midnite. I don't know the specifics but I do know this was a plan for 3rd party developers to have access to data on the server at my midnite.
Ryan
Hey guys, I love the potential to do remote access etc, but for me and a lot of other semi-geek types we do not have Inet access (other than for vast amounts of $$$$.00) so need these tools to operate on/ from a stand alone PC or rPi type box, and to collect that data manually ( well, a 3 hr one way drive).... so PLEASE don't forget about us too, ie if it will rPi it, it should be able to Net it ...
Quote from: Westbranch on June 10, 2013, 10:48:13 PM
Hey guys, I love the potential to do remote access etc, but for me and a lot of other semi-geek types we do not have Inet access (other than for vast amounts of $$$$.00) so need these tools to operate on/ from a stand alone PC or rPi type box, and to collect that data manually ( well, a 3 hr one way drive).... so PLEASE don't forget about us too, ie if it will rPi it, it should be able to Net it ...
Amen.
I still want to do something mean to whomever put the S in SNMP