IOT stands for “Internet Of Things” for those who have not heard the term yet. It means the connection of all things which can talk to other things but are not really computers as such. Of course they are some sort of computer in the broadest sense but they are not PCs or systems meant for any interaction other than a specific purpose. Some say “anything that has an on/off switch” can be part of IoT eventually. This includes fridges, washing machines, microwaves, lights, heaters and so on. Many have a smart TV which is connected to the Internet. You can view program streams, browse web sites but also have the firmware of the TV updated and have service people running a diagnostic program from remote terminals. This is also true for the Victron components when remote assist is enabled, however the functionality is a bit limited because you cannot update the Multiplus firmware over the Internet for example. One can update the CCGX but not the other components. What is the benefit one may ask: Updating firmware in devices is one obvious one, remote diagnostics another, but many applications where it is useful are remote applications or security applications. Ip cameras are connected to the Internet and streaming pictures and can be remote controlled to sweep an area of interest etc. For the van it means that I have access to all components from wherever I need to with the limitation of distance when no Internet connection is available. I can only connect with a range of 10-20 km of Wifi coverage depending on terrain when no Internet is available. How is this useful for a caravan ? Security is one aspect. Motion detection and streaming cameras will help to identify threads when away. Smoke detectors, temperature sensors, pressure sensors etc. can identify problem areas to be addressed before real damage occurs. Monitoring the solar system and battery charge, adjusting temperature settings of the aircondition system or receiving a warning message when the freezer temperature climbs unexpectedly are only a few of the applications.
I have decided to connected as many components as I can to my local net and make access available through a central gateway to all my components and this includes the DC-DC charger.
I have finished testing the charger with a real Lithium battery and removed all the kinks in the software. I added 5 configurations switches on the rear panel, which allow immediate control of some functions without using the central screen or a remote tablet. Enable/disable, display on/off, display options and soft charge are some of the options. To record actual charge curves with reasonable accuracy one needs to sample the battery voltage frequently and transfer the readings to the central system. Communication speed on the bus is somehow essential to allow all the required traffic on the net without holding up some functions. At this stage I have not written a software stack of requests and responses, but service each request sequentially, which means I wait for the response before I send the next request. This may change in future when I see the need, but so far it appears to be sufficient when the response time is short enough and I do not run into frequent timeout situations. I have now optimised all my Can-bus components and achieved an overall response time of typical 16-17 ms for a Can-bus request. This means the central system sends a request via Ethernet to the gateway and then the message is forwarded onto the Can-bus. The relevant client responds and the gateway forwards the message to the central system. This happens in 16ms per request. The turnaround for a message to the gateway alone is 6-7ms, which means the typical response time of an Arduino with the Can-interface is around 10ms. This is as good as it gets in my application.
I added the field elapsed time to my test panel and can now see the response time for each request type of the network. Eventually I will also adapt a boot loader to the Can-Bus protocol to actually make firmware updates of my components through the Can-bus and not the USB port of the Arduino. Solutions for Ethernet exist using TFTP (Trivial File Transfer Protocol) and can be adapted to the Can-bus in my case, but this is for much later.
I have not received any answer from Victron as expected really. Talked to my supplier and he has confirmed this not being unusual. The CCGX documentation is more than poor, so is some of the other documentation. It took me a while trying to get the information I need for the Modbus/TCP until I realised that I overlooked a workbook in an Excel file which I had downloaded from Victron. Now I have everything to monitor the components. I am waiting for a MK2-USB cable which I need to update the firmware of the Multis. A new MK3-USB is expected I was told but I am not going to wait for this. I want to update the Multis and see if the display of the CCGX makes more sense. I also will have the Modbus implementation by then and can see the actual data coming from the components and may be able to verify and explain what I actually see on the CCGX. Currently I see negative watt values for AC in, which is really not possible and should be cleaned up by software. Negative watts are only possible if I would grid feed, which is not the case. The only explanation is that the current sensors in the supply line delivers arbitrary values when no AC is connected and the reading is not cleaned up by software. Anyway, maybe I am too picky, but when you pay some $800 for a component you expect that it makes some sense what to see or at least have a proper explanation and description of the unit.
I also have decided to replace the step up power supplies in the DC-DC charger with higher current ones. I will have a 30 Amp and a better 10 Amp unit with a built in fan for cooling. The current levelling controller draws up to 20 Amps per leg and moves up to two legs at the same time. My controller can actually move all 4 legs and I want the DC-DC charger to curb some of that load when using the leveller. Same applies to to brake actuator. It draws around 30 Amps and the DC-DC charger can cope with this keeping the trailer battery nicely charged. I decided not to use a third battery as UPS for the central system, but use the trailer battery for both the brake away system and the emergency supply for the central system when both house banks are off-line. I repaired my older trailer battery which blew a cell from overcharging. I replaced the defective cell, balanced the cells and now it is ready for service again and I will run the two 40 Ah batteries in parallel. This is plenty capacity for the trailer operation and a UPS for all the electronics.