Sometimes it easier to see the awkwardness of a solution when someone else tries the same thing. To this end, I present DWML, http://graphical.weather.gov/xml/DWMLgen/schema/DWML.xsd a standard for distributing weather predictions.
As that is a little inaccessible, look at the example:
http://graphical.weather.gov/xml/DWMLgen/schema/latest_DWMLByDay24hr.txt
(First, and hearkening back to an earlier thread, this example shows how messy time ranges are when not defined parametrically using Avaliability)
But back to this thread, the National Weather Service has
<weather time-layout="k-p24h-n7-1">
<name>Weather Type, Coverage, and Intensity</name>
<weather-conditions weather-summary="Snow Likely">
<value coverage="likely" intensity="light" weather-type="snow" qualifier="none"/>
</weather-conditions>
<weather-conditions weather-summary="Snow Likely">
<value coverage="likely" intensity="light" weather-type="snow" qualifier="none"/>
</weather-conditions>
<weather-conditions weather-summary="Chance Snow">
<value coverage="chance" intensity="light" weather-type="snow" qualifier="none"/>
</weather-conditions>
<weather-conditions weather-summary="Slight Chance Snow">
<value coverage="slight chance" intensity="light" weather-type="snow" qualifier="none"/>
</weather-conditions>
<weather-conditions weather-summary="Mostly Cloudy"/>
<weather-conditions weather-summary="Chance Snow">
<value coverage="chance" intensity="light" weather-type="snow" qualifier="none"/>
</weather-conditions>
<weather-conditions weather-summary="Mostly Cloudy"/>
</weather>
<conditions-icon type="forecast-NWS" time-layout="k-p24h-n7-1">
<name>Conditions Icons</name>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/sn30.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/sn60.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/sn30.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/sn20.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/bkn.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/sn30.jpg</icon-link>
<icon-link>http://www.nws.noaa.gov/weather/images/fcicons/bkn.jpg</icon-link>
</conditions-icon>
<hazards time-layout="k-p6h-n1-3">
THis snippet of XML expects the conditions and the icons will line up. It provides a list of weather related icons to use if the XML parser preserves order (which is not required by the XML spec)
I think this is on the same topic in a different space.
I think this would be better as an extensible type of enumerated icon types.
A particular brand could use a different icon library if it wants.
Many (most) devices will cache their list of icons, but an unknown icon can always be downloaded on demand.
There may be request to "update your icon library", as times, fashions, corporate ownership change.
A Charge-Station maker can choose whether to hard-code a set of icons at the factory, or to optimize for more use of cache in low communications scenarios, or to optimize for more use of communications.
As I write this, I see a need to be able to transmit "base URL for your new Icon library". Perhaps there is a way to request standard icons in 8x8, 16x16, 64x64 or 320 by 320 pixel versions as a device capability. (Perhps this happens when a Charging Network changes hands...)
That is if I understand the discussion, and the hardware/communications trade-offs
We should design this spec as a platform for evolution of business process, not locking in the particular hardware choices for today.
|
graphical.weather.gov
meteorological forecast 2008-12-05T19:38:31Z http://www.nws.noaa.gov/forecasts/xml/ Meteorological Development Laboratory Product Generation Branch http://www.nws ...
|
|
graphical.weather.gov
This _expression_ enforces a space delimited list of latitude longitude pairs. The latitude and longitude values are delimited by a comma ...
|
Sent: Thursday, November 10, 2016 6:53:35 AM
To: robert.de.leeuw@ihomer.nl
Cc: ocpp@lists.oasis-open.org
Subject: AW: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
Hi Robert,
I have missed the last queation:
"3. The message should support graphic elements (from your example a Santa Claus picture)"
Is this a SHOULD or a nice to have?
on a 20x2 (or 20x4) display you could display a smiley or any other pictogram. I think we should keep this option open.
Greetings
Mit freundlichen Grüßen / Kind regards
i. A. Dr.-Ing.
Sergiu Tcaciuc
Seniormanager
Softwareentwicklung
eMobility
|
Tel. +49 (0) 27 23 / 41-6 47
|
|
MENNEKES Elektrotechnik
|
|
AG Siegen HR A 6577 Komplementärin / Unlimited Partner:
|
Zur
Einladung...
Werden Sie Teil eines starken Teams und erleben Sie wie
spannend die Arbeit in einem internationalen Unternehmen ist!
Jetzt ONLINE bewerben:
www.MENNEKES.de/Stellenmarkt
Von:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
Im Auftrag von Robert de Leeuw
Gesendet: Dienstag, 8. November 2016 10:27
An: ocpp@lists.oasis-open.org
Betreff: Re: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
Hi Sergiu,
Great input!
What do you mean with "cycle"?
"2. The
message should support different screen levels (Single line B&W, multiline B&W, multiline Color etc. )"
Do you mean that with 1 message can contain all of these in one message so the same message can be send to different Charge Points? Or that the message has to be able to support different types
of display: multi line, single line, B&W and Color?
Is Color a SHOULD or a nice to have?
"3. The message should support graphic elements (from your example a Santa Claus picture)"
Is this a SHOULD or a nice to have?
Kind regards,
Robert de Leeuw
IHomer
Hoge Ham 85
5104 JC Dongen
John F. Kennedylaan 3
5555 XC Valkenswaard
T: +31 6 2857 2123
E: robert.de.leeuw@ihomer.nl
2016-11-08 9:41 GMT+01:00 <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
i. A. Dr.-Ing.
Sergiu Tcaciuc
Seniormanager
Softwareentwicklung
eMobility
|
Tel. +49 (0) 27 23 / 41-6 47
|
|
MENNEKES Elektrotechnik
|
|
AG Siegen HR A 6577 Komplementärin / Unlimited Partner:
|
Zur
Einladung...
Werden Sie Teil eines starken Teams und erleben Sie wie
spannend die Arbeit in einem internationalen Unternehmen ist!
Jetzt ONLINE bewerben:
www.MENNEKES.de/Stellenmarkt
Von:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
Im Auftrag von Robert de Leeuw
Gesendet: Montag, 7. November 2016 17:13
An: ocpp@lists.oasis-open.org
Betreff: [ocpp] OASIS OCPP: Use Cases for show message on Charge Point wanted
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,
Robert de Leeuw
IHomer
Hoge Ham 85
5104 JC Dongen
John F. Kennedylaan 3
5555 XC Valkenswaard
T: +31 6 2857 2123
E: robert.de.leeuw@ihomer.nl