[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
Hi Robert, (All), (It seems you did not reply to the ocpp group address, so your comments were not shared). I take your point that templating/placeholders for local information display would primarily be applicable to the “tariffing & costing” area (CR), but there are other possible cases of interpolated local information (e.g. (site) opening hours, ambient temperature information display: “It is currently $AMBTEMP degrees $TEMPUNITLETTER”). My point was that on these very constrained displays, ongoing “charging info” will typically be one (or maybe two: duration + energy, and rate+cost) frames of a possibly wider set of rotating frames on a typical 2x20 monochrome LCD character display. I was assuming that the costing & tariffing area solution will probably require a static text templates + metered variable interpolation approach on a per-language basis, if internationalization and bi-lingual territories (e.g. Belgium) are to be included, and it would be useful to not have two divergent systems for “tariffing & costing” and “general notices”. Best Regards, Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie From: Robert de Leeuw [mailto:robert.de.leeuw@ihomer.nl] Hi Brendan (and All) Interesting and importand input, thanks. I specially like to URL for complex charge points. I can see that work. Especially if you want to show something with images on the display. Sending the image over OCPP doesn't seem like a simple solution, using a URL (for a webpage) will work in such a situation... I'm a bit in doubt about: "To support the display of locally measured/computed information in the case of offline operation (e.g. charging duration, delivered kWh, locally computed cost), it is desirable that some standardized text content template & variable substitution placeholder mechanism be defined" This is for a “Small” displays". I think we should keep things simpel for a simpel charge point. And I don't think this CR Messages is for Charging related stuff, it should be for special messages. So I don't see the need for templating... but that might be just me... ;-) Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
2016-11-08 12:12 GMT+01:00 Brendan McMahon <Brendan.McMahon@esb.ie>: Hi All, Sergiu identifies a number of very good points, to which I would like to add some further points on this subject that have been discussed in various fora, at various times in the past. Taking a slightly wider picture, there are two broad visual display hardware class cases that have overlap, but also have significant differences in possible use case scope: 1. “Small” displays, commonly encountered on less sophisticated, low power, long-stay charging equipment. These are usually limited by one (or often many) of the following constraints: · Character mode display devices o Limited character set § 128/256 element (usually fixed) character set (e.g. ASCII/ANSI) o Limited display width (expressed in character columns; very often as low as 20) o Limited display rows (expressed in lines, very often as low as 2) o Monochrome display For these types of display, it will be essential for the characteristics/constraints to be communicated by the Charge Point to the Central System using the Device Model, as part of the enrolment/inventory mechanism. Given the wide variation of these constraints between charging equipment, it will most likely be necessary for the format and content of the display text to be decided at the controlling Central System (either automatically, or with prior human assistance (via templates, etc.). Because of the often very limited display “real estate”, information of a supplementary/secondary nature will often need to be alternated with “primary” information (charging progress status, energy transferred, cost, etc.) as part of a repeating cycle of display “frames”, each of whose content and display duration are individually controllable by the Central System. To support the display of locally measured/computed information in the case of offline operation (e.g. charging duration, delivered kWh, locally computed cost), it is desirable that some standardized text content template & variable substitution placeholder mechanism be defined. 2. “Graphic” displays, most often encountered on more sophisticated (and increasingly high-power) charging stations. These are already common on complicated high power multi-standard charging equipment, where they are now typically used primarily/solely to convey operating instructions. They typically feature pixel resolutions of at least VGA (640 x 480), colour, and often touch screen, or edge aligned multi-function UI input buttons. With products and plans from various EV and charging equipment vendors for charging rates of up to 300kW and more in coming years, there is an increasing likelihood that the EV driver may remain in the vehicle for (much of) the duration of the shorter charging time, and consequently there will be a requirement for more sophisticated information communication (from possibly large screens) that is often incidental to the vehicle recharging activity: e.g. cross-selling & up-selling of linked products/plans/services, general or site specific advertising, etc. Assuming that the embedded computers driving such hardware will most likely be based on common operating systems & software, it is highly probable that to avoid “re-inventing the (giant) wheel”, such display content will need to be based on standard web technologies (HTML, CSS, _javascript_, etc.) and use off the shelf web browser software running in “kiosk mode”. If that be the case, such content can be initiated/managed from a Central System very simply, just by sending a starting URL (together possibly with an indication of whether the host from which the web resources are to be retrieved is to be accessed via the public internet, or via a private (is such exists)). Best Regards, Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] On Behalf Of sergiu.tcaciuc@MENNEKES.de Hello Robert, We had a similar subject for some time (we did not got a solution). The following requirements for a custom message was relevant: 1. The message should fit into one sub-screen (a list of sub-screens displayed during one state in a cycle. The cycle relates as long as the state persist) 2. The message should support different screen levels (Single line B&W, multiline B&W, multiline Color etc. ) 3. The message should support graphic elements (from your example a Santa Claus picture) 4. The message should support simple multiline formatting elements (like CSS: Size, Font, Color etc.) 5. The message should support different languages (Unicode?) 6. The message should include the minimum display time in a cycle 7. The message can include the overlay priority (display on top of all screens or between the screens at the cycle end) 8. The message can include the maximum display time in a cycle 9. The message can include a validity period or number of cycles 10. The message can include the charging point state when is should be displayed (ex. only in idle) As examples i would add: - Display bonus information - Display personalized greetings Hope this can be helpful for you. Mit freundlichen Grüßen / Kind regards
Von: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] Im Auftrag von Robert de Leeuw Hi All. There was an idea for a CR about sending a message/text to a Charge Point that should be displayed on the Charge Point if it has a display. Are there companies in this TC with use cases for this? Requirements? Can you please provide these? Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** * |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]