Encryption OFF

[dgd]

These are all the 1% type asks that Ryan is talking about. They already have several ways to talk to it and you want several more. Id go along with: if mymidnite is disabled to allow a second modbus connection, if its practical to code. Itd make my life easier for sure, but its not a deal breaker honestly. My plan is real simple, to have a button on blackbox UI, that says enable/disable classic link. Using the local app is then a simple matter of clicking disable, doing your business then renabling it. Its not ideal but will work. As i said the other day, it would also be possible to build the local app config functions into the blackbox, and be free of Air for good.

I only want that second TCP connection made public. Pity if it is that 1% ask category.

The blackbox is another separate project, possibly a longer term development  and I agree the possibilities are interesting.
Maybe we should have an MN combox discussion, separating possible harware specs from software requirements. Maybe most of both is done already.

dgd

[zoneblue]

BTW the latest newmodbus (daemon version) is here:

http://code.google.com/p/theblackboxproject/source/browse/trunk/c/newmodbusd/source/newmodbusd.c

[zoneblue]

I agree some planning is a good idea.

The objectives document that ross and i threw together is here:

http://code.google.com/p/theblackboxproject/wiki/Planning

Its a wiki, if you want a login i can sort that out. Threres also a lot of discussion on the hardware side in the subforum, here, that is yet to be rationalised and included.

[atop8918]

Hi, guys,
These are all good points and requests. Again, we're not trying to hold out on you by being stubborn: it takes a lot of time to do these things, otherwise we would have them done. For me to accurately document the handshaking process would probably take a day or two of work including getting back into the code and making sure there are no changes since the original design document. This is also Company Proprietary stuff. If I pass this out then competitors also see it and it is part of our IP meaning we could face competition right away. Also by handing out encryption keys, which though I truly believe belong to you as the customer, we run the risk of malicious folks getting their hands on them and starting to (really) hack our system (I spend a lot of time thwarting hacking on the website as it is now). In addition to all of this I will also be tasked with answering any questions relating to helping 3rd parties try to get the handshaking to work. I simply do not have any hours left in the day to do this. 16 a day is all I can manage and still have a little time for my children and some sleep once in a while.
We designed the communications in the Classic to compete with our nearest competitors and provide two plug-and-play interfaces: the Local Application and MyMidNite. If these are not useful to some customers then the weight of additional features unfortunately rests with you (unless you can pay us for the additional development time and resources or buy 1000+ units). We are open and willing to provide any features that we can fit into the schedule and will provide us with additional sales to compensate for the development time, but we can't spend a lot of additional time on features that won't improve our sales -- that makes us lose money which we really can't do at this point.

To add another TCP connection I would have to implement system-wide mutex locking. I would have to re-architect the modbus stack. In fact, I would have to do all the things that were deemed too time-consuming and unnecessary way back when we were initially designing the communications. So I'm afraid one connection is all that there will ever be on the Classic. Just like one Start button on Windows, or one App Store on iOS, or one screen on the iPhone.

That having been said, please, please, please keep suggesting features. You guys are awesome and have pushed the Classic along very well with many of the things you have thought of. We do value your opinions and suggestions, we just cannot possibly implement them all.

[Halfcrazy]

Now to the Classic, no matter how smart the code is I write and does what I want, the overwhelming and crippling limitation of the Classic is its ONE and ONLY TCP connection. I cannot have a permanent PC connection via TCP to gather and live report or archive data as I can then not connect remotely with say the Local App to get a snapshot of how things are going.


dgd

You guys do realize there are unlimited RS232 connections available? It is independent of the TCP/IP so no matter how bad we may have "Crippled" the controller there is still another port.....

[ClassicCrazy]

I wonder if a Beaglebone Black or a Raspberry Pi could connect to both TCP and serial at the same time and display all the data via webserver ? I am still novice learning the Linux world but that seems like it would solve some of these issues inexpensively.

[zoneblue]

You guys do realize there are unlimited RS232 connections available? It is independent of the TCP/IP so no matter how bad we may have "Crippled" the controller there is still another port.....

I was put off put off by a couple of folk that said they tried using serial and found it error prone.

Where would we find documentation for the serial port? Im interested in testing it, for one thing it will save 2 watts or so.

Could we also have an updated modbus register doc, as there are now *way* more registers than the May13 doc.

[ClassicCrazy]

I am curious - what is the two watt savings from ?

[TomW]

I was put off put off by a couple of folk that said they tried using serial and found it error prone.

I had these issues but it was an rPi limitation not the Classic itself. It basically just dumps the data so if your collection machine has to use resources for something else on the communications chip (serial,ethernet) the data can get corrupted / truncated.

From memory.

Tom

[Halfcrazy]

Yes the RS232 should be very stable.

[zoneblue]

The 2W is basically the ethernet switch needed to link the classic, blackbox, and the LAN.

The blackbox itself only uses 1.25W, but that also includes about 0.6W for its plugged ethernet link.

Then theres whatever the classic uses maintaining its end of the connection. So total could be higher than 2W.

[ClassicCrazy]

Glad to hear you analyze power consumption  use in watts instead of amps. Every day I see so much power wasted everywhere where I work it would almost be a joke if I suggested saving a watt. You must have a very efficient system.

[dgd]

Yes the RS232 should be very stable.

It is but slow 9k6 or 19k2 modbus throughput.
There is not a lot of real time processing you can do at this comms speed

[dgd]

Or if you had the DES key you could decrpyt it...  Still for most datalogging purposes the fixed 15 minute interval is likely to be too long, yeah?

The interval appears to be a function of the handshaking. In early days of Mymidnite release there was a while when a one minute interval was running. That made the data very useful.
Unfortunately my suggestions to have a user specified interval time from 1 to x minutes was rejected, even though this would mean just a couple of days data retention instead of 2 weeks worth with a 10 minute interval.
This is one of the first changes I would make if able to redirect handshaking to a local server.

dgd

[dgd]

Hi, guys,
These are all good points and requests. Again, we're not trying to hold out on you by being stubborn: it takes a lot of time to do these things, otherwise we would have them done. For me to accurately document the handshaking process would probably take a day or two of work including getting back into the code and making sure there are no changes since the original design document.

I know that you know as a professional systems/applications programmer that maintaining up-to-date documentation is essential. I'm sure that if MN management were made aware of the necessity of this task that they would allocate your resources to complete this necessary task.
Then providing this info would be so simple.

This is also Company Proprietary stuff. If I pass this out then competitors also see it and it is part of our IP meaning we could face competition right away.

Ok, I have never known any form of handshaking protocol or sequence be a significant risk to a company survival. However if MN management share your view then this becomes an immovable blocker to any further progress on opening this Mymidnite communications channel.
I would greatly encourage you and MN to lean more to open documentation (and source but MN already closed this idea)

Also by handing out encryption keys, which though I truly believe belong to you as the customer, we run the risk of malicious folks getting their hands on them and starting to (really) hack our system (I spend a lot of time thwarting hacking on the website as it is now).

I cannot understand the purpose of the data encryption. Only the actual data items appear to be encrypted as I'm not aware that the TCP header/routing info is encrypted.
So the only purpose of this appears to be to deny the owners of the data from using any security or data comms analysis tools to confirm that only performace data/Classic ID info is actually being transmitted.

I think you have this the wrong way around.
If, as you say, you already spend time dealing with malicious hacking of the server then my main concern would be that the server becomes compromised, or already has been, and malware/spyware is already installed there OR the server is linked to another compromised/malware server.
If this does happend then the server has a hidden and somewhat secure data link to a network device on customer's networks.
I can't see the unencrypted data stream so the Mymidnite server could be being used to investigate possible security openings on networks the Classic is connected to.

This however is not why I want decryption, I just want access to my data on my network then I can start doing something useful with it.

In addition to all of this I will also be tasked with answering any questions relating to helping 3rd parties try to get the handshaking to work. I simply do not have any hours left in the day to do this. 16 a day is all I can manage and still have a little time for my children and some sleep once in a while.

That, with respect, is an MN management issue and they should resolve this.

We designed the communications in the Classic to compete with our nearest competitors and provide two plug-and-play interfaces: the Local Application and MyMidNite.

Ok I could say lots about this, just briefly, design for customers not competitors.
Not by any measure is the Localapp and Mymidnite within the definition of Plug and Play. Sorry, but they are both relatively complex bespoke programs needing significant effort to set up and get going.

If these are not useful to some customers then the weight of additional features unfortunately rests with you (unless you can pay us for the additional development time and resources or buy 1000+ units).

This is just another way of saying If you are not satisfied with our software offerings then don't buy our products

We are open and willing to provide any features that we can fit into the schedule and will provide us with additional sales to compensate for the development time, but we can't spend a lot of additional time on features that won't improve our sales -- that makes us lose money which we really can't do at this point.

ok, this is meaningless to me.  Maybe thats a company requirement  but it just discourages any desire from users to think they can contribute to product improvements.

To add another TCP connection I would have to implement system-wide mutex locking. I would have to re-architect the modbus stack. In fact, I would have to do all the things that were deemed too time-consuming and unnecessary way back when we were initially designing the communications. So I'm afraid one connection is all that there will ever be on the Classic. Just like one Start button on Windows, or one App Store on iOS, or one screen on the iPhone.

Sorry I had forgotten that you had already told me in a previous message that you have written the Classic's TCP stack routines.  That in itself just seems incredible to me as there are just so any available TCP stack software packages available (IPv4 IPv6, written in ANSI C and trimmable for embedded cpu systems).
So without mutual exclusion processing it would seem your Classic stack is barely minimum.

Without intending to detract from your efforts and expertise, it is a pity that the TCP stack was not implemented properly in the first place then we wouldn't have this ridiculous crippled TCP connection limit with the Classic.

The Classic has been with us for 4+ years now. In all that time the stack issues could never have been revisited and resolved?

That having been said, please, please, please keep suggesting features. You guys are awesome and have pushed the Classic along very well with many of the things you have thought of. We do value your opinions and suggestions, we just cannot possibly implement them all.

Sorry but this almost seems pointless now.
I can think of many many suggestions for improvements made by forum users but nearly all are ignored.
Errors and bugs do get attended to promptly, as you would expect, dead simple cosmetic changes may get attention but everything else, cosmetic or more serious, generally get nowhere.

If its an actively being worked on feature such as the SOC processing then suggestions meet with more success.
If its the local app then nothing.

NOTE:  No offence or annoyance was intended towards anyone by this reply. I am not attacking anyone BUT just trying to speak plainly and honestly.

dgd