Dear Jan,
(1) Yes. We do the same thing (e.g MSDevice_Tripinfo::notifyEnter)
(2) I don't understand why the type of simulation needs to be known within HelpersEnergy:compute(). Can you elaborate?
(3) If all you need is a lookup from lanes to an ID there may be better ways to approach this. You could define polygons with <param> elements to identify them as overhead lines for a particular lane, then create a static map between lanes and lines from the polygon data (and get a slick colored visualization on top)
e.g.
<poly id="caternay_123" color="red" width="0.1">
<param key="lanes" value="lane1 lane2 lane3"/>
<poly>
(4) The code that triggers the output for each object can go into MSNet but anything on top of that I would put into a separate class
(5) Vehicle stopping on the road due to empty batteries should still be an exceptional case and I would make any custom behavior in this situation optional. Instead of setting the speed to 0 I would use either of the following two approaches
a) adding a stop for some a fixed duration (similar to --collision.stoptime)
b) using veh->getInfluencer().setSpeedTimeLine(speedTimeLine) to let the vehicle stop for a specified duration (see libsumo/Vehicle::slowDown)
Regarding the error mesoscopic model documentation, you are correct. I've removed public transport from the list of limitations.
It would help if you could describe how your extension differs from the existing electrical vehicle model. In particular I would like to figure out whether it would make sense to generalize the existing battery device rather than adding another device. Tracking of substations / energy network usage might be a reason but there may be better places than a vehicle device to do so.
best regards,
Jakob