Staring at computer trying to figure out why I can't read a float from modbus. I swapped the bytes correctly for my platform. I also ensured the endianess of the words matched my platform (byte endianess is not the sames as word endianess, fml). Was driving home thinking about what could be wrong. My mind saw this code:

uint32_t newint;
for(int count=0; count<2; count++){
newint |= words[count] << count;
}

Then I am fuck! It should be:
newint |= words[count] << (count*16);

This was later turned into float. I kept getting values in the 1e-40 or some shit. Now it makes sense. The upper word was not set.

This is such newb shit. Fuck you newb shit I should just know!

Reading more I realized that the endianess of words can vary between devices even though the spec calls for big endian words. Fuck you non-compliant vendors! So I gotta add a flag for fucked up devices. Fine. The pay off is a generic way to add modbus to our opcua server. I want this easily editable in the field. For now it is readonly. So that makes it nicer.

Just a little torqued that I solved this driving home instead of at work. Too close to the code. I think tomorrow I will have my boss review it to tell me of other logical crap I missed.

So I get to work on building a client at work for industrial automation. I am building a mini hmi to show customers how our server works. The code uses opcua. The reason I am making a client is because all the opcua hmis on the market are really expensive. There is nothing less than $600. There are hmis for free out there, but none of them say they support opcua. opcua has become a major protocol in the industrial automation industry.

It took me about 2 days to gin together a client that is pretty much abstracted and will be easy to maintain. A lot of that was just learning the opcua library client code.

Now I want to create servers and clients geared toward home automation for fun and profit. I want to take sensor data from arduinos using a simple serial protocol like modbus or other protocols that are supported. Then have an opcua server that collects this data. Then finally have an opcua hmi that I develop talk to these servers. The security model is much better and would be compatible with other vendors clients/servers. I already have a game engine I want to use for the hmi portion. It has tons of widgets for displaying data, graphs, lists, text, etc. It does both 2d and 3d.

This sounds like a project that could really fun, meshes with my work learning, and provides value to people that want to automate their lives.

The other side effect is that the next time I go looking for a simple and cheap hmi that supports opcua, there will be one.

How much trouble am I asking for in allowing for very large strings in attributes of json data?

I went and looked at the maximums for the string in json strings. I cannot see any real limitations. I did see if sending json data to a browser that it should not be more than 40MB. That seems excessive. I also checked my internal data types. The string can hold 2GB. Then there is a the server it will be served from in OPCUA. Which I saw discussion of strings in the 77KB range.

We are using a json file to configure what points to read from a modbus device. I am adding fields for name and notes. I could limit these fields, but part of me wants to see if some customer tries to make the world burn. For the most part we will be editing this file. But the customer may want to as well.