Open PA1RB opened 3 years ago
We like to implement the smart features also in the sensorbox, which has a wifi interface as well. When sensorbox is present, it could take control over the modbus communication (act as master device), and it would be able to do additional tasks like provide information over Modbus TCP, act as RTU <-> TCP gateway or also implement other protocols.
OK, excellent news, and the approach to let the Sensorbox take the master (sorry, client :innocent:) role in that set-up makes perfect sense to me.
In case Sensorbox-2 already has the required hardware capabilities, and the team is willing to publish code and schematics, I would be happy to contribute to the concept and/or the code.
If the feature is already in development and you want to hold-off publication until a minimal viable product is ready, can you then share a guesstimated target date please?
Excellent news, i'm struggling to get te communication between the evse and sensorbox via an RS485 - wifi gateway as the distance between is not convenient to overcome by cable, too match digging. No luck so far. If this is build in functionality that would be a great help. Any progress on this part is very much appreciated. Any procedure to activate the wifi part in the Sensorbox 2 will be helpful as wel
You can use Node-Red (with Raspberry PI) make MQTT possible with a RS485 USB adapter.
Via this way you also can make the MODBUS transfer via WiFi or Lan.
Any news in enabling the wifi in the sensorbox? I would also like to intergrate into my home automation and before I put too much effort in trying to add my own modbus master on a bus which already has a master I would like to know if the sensorbox code is almost ready for wifi. Also when will that code (if ever) be available for public?
You can maybe check this code and see if you can use it? https://github.com/ict-one-nl/mqtt-to-smartevse
You can maybe check this code and see if you can use it? https://github.com/ict-one-nl/mqtt-to-smartevse
This is exactly what I meant with a double modbus master which I would like to prevent.
Any news in enabling the wifi in the sensorbox? I would also like to intergrate into my home automation and before I put too much effort in trying to add my own modbus master on a bus which already has a master I would like to know if the sensorbox code is almost ready for wifi. Also when will that code (if ever) be available for public?
I've heard from Stegen that the Sensorbox V2 PCB and source code will be published this week.
Some users have existig own smart meters and for example in detached garage from house sometimes is hard to route any additional wires from modbus smart meter to EVSE box. So MQTT integration sounds good when you have some home automation runing, would be nice that Sensorbox could "subscribe" via mqtt and lookup for power usage values in smart House systems like Home Assistant, Openhab and etc.
Any updates on this?
This guy is making modification to the smartevse v3 code which adds integrations: https://github.com/serkri/SmartEVSE-3 You need a v3 smartevse for this though.
thanks @IgorYbema
I am about to start working on a solution to integrate SmartEVSE into home automation, in my case that would be Home Assistant.
The idea is to create an additional physical
slave(pardon: server) device (let's call it a bridge), hooked to the Modbus RTU bus of the SmartEVSE system, that holds a copy of certain registers of the SmartEVSE controllers, which can be updated and read by the primary SmartEVSE controller. The value of these registers is in-turn exchanged by the bridge with Home Assistant based on the MQTT protocol over ethernet.In a first iteration, the primary EVSE controller will only write information to the bridge. This will allow the home automation system to monitor the SmartEVSE controller's states and certain values.
In a future iteration, the primary EVSE controller will also read information from the bridge that was pushed there from the home automation system, thereby influencing the charge process based on various rules within Home Assistant. These rules can include planning charge time and charge speed based on planned travel schedules, cost of electricity and/or knowledge from the car itself like battery state, etc.
I plan to take an approach where I leave the operation of SmartEVSE as-is, and ensure it will continue to operate as usual and autonomously in case of absence of a connection to the bridge. Also, none of the EVSE safety-related parameters shall be write-accessible through MQTT.
Potentially the device may include the functionality of a Sensorbox to reduce the number of required devices, but I do not pursue that myself.
Any interest in or thoughts on this approach? Anyone who already started on a similar solution?