Connectivity Enhancements #526
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,3 +23,141 @@ IsConnectivityAvailable: | |
| comment: This signal can be used by onboard vehicle services to decide what features that | ||
| shall be offered to the driver, for example disable the 'check for update' button if vehicle does | ||
| not have connectivity. | ||
|
|
||
| ConnectivityType: | ||
| datatype: string[] | ||
| type: attribute | ||
| allowed: [ | ||
| 'CELLULAR', | ||
| 'WLAN' | ||
| ] | ||
| description: Type of connectivity currently available. | ||
|
|
||
| CurrentDownload: | ||
| datatype: float | ||
| type: sensor | ||
| unit: MiB/s | ||
| description: Download bandwidth currently in-use. | ||
|
|
||
| CurrentUpload: | ||
| datatype: float | ||
| type: sensor | ||
| unit: MiB/s | ||
| description: Upload bandwidth currently in-use. | ||
|
|
||
| Cellular: | ||
| type: branch | ||
| description: Properties related to cellular connectivity. | ||
|
|
||
| Cellular.SignalStrength: | ||
| type: sensor | ||
| datatype: int8 | ||
| unit: dBm | ||
| description: Cellular connectivity signal strength. | ||
|
Comment on lines
+52
to
+56
There was a problem hiding this comment. This is defined as int8 (-128 to 127) for both WiFi and cellular. Given that dBm is a logarithmic scale, I didn't see a scenario where the signal strength could stray outside of this range, but it is a bit tight. Alternatively, would this be better as a percentage (0-100%)? There was a problem hiding this comment. We also have float as an option. Historically in VSS when selecting datatype we typically consider expected range and if decimal notation is required. If we see it unlikely that someone needs decimals for the given unit we select an int-type that fits what we see as a reasonable range. (What datatype that then is used in a real deployment could differ). Concerning using percentage - In user interfaces you rarely see the absolute value but rather a relative value like number of "bars" where 4 bars may indicate excellent signal strength and 1 bar bad signal strength. But I do not know if there is any industry standard or convention converting between dBM and percentage/bars or if that is only in relationship to what the device expects. I.e. X dBM might mean 40% for one device but 20% for another device? In the long run maybe we need both an absolute signal (dBM) and a relative signal (starts/bars/percent) as they might serve different purposes. Maybe the OEM want to collect absolute dBM values, but the HMI wants to show the relative value. If we start with absolute, if that fits your use case, we could always add relative later. There was a problem hiding this comment. I can see value to both absolute and relative, for sure. I think absolute could be useful for things like vehicle diagnostics and troubleshooting. There isn't really a standard conversion between dBm and percentage, but I think most implementations are at least similar. Because actual connectivity drops off much faster at low connections, many companies actually choose to drop percentage faster as they get to the lower range, so it isn't always linear either. I think I'll revise this part to include both. Also, I've never seen dBm measured in floats when working with real-world modems, so I'm not sure that is needed but can be changed if you guys think so. |
||
|
|
||
| Cellular.SignalStrength.Relative: | ||
| type: sensor | ||
| datatype: uint8 | ||
| unit: percent | ||
| min: 0 | ||
| max: 100 | ||
| description: Cellular connectivity signal strength in percent. | ||
|
|
||
| Cellular.NetworkType: | ||
| datatype: string[] | ||
| type: sensor | ||
| allowed: [ | ||
| '2G', | ||
|
There was a problem hiding this comment. I think this datapoint is useful, but too generic, like 2G might be EDGE or even only GPRS, 3G could be HSUPA or HSDPA, 5G might be -SA or -NSA etc. Maybe it might make sense to align to Android, not sure how to get a good List, but basically something like the getdatanetworktype() returns in TelephonyManager https://developer.android.com/reference/kotlin/android/telephony/TelephonyManager#getdatanetworktype There was a problem hiding this comment. Those might not always be represented to the user in a UI, but if you imagine some services deciding what to services can run, what to traffic shape etc. this information among others might be relevant. Toy example: If you do trickle downloads of software over cellular, maybe cellular, maybe with HSDPA (3G) and good signal strength you would do it, but with UMTS (3G) definitely not, or your user might have issues using connected navigation or off-board speech recognition. There was a problem hiding this comment. I actually agree, and that was the intended purpose of Cellular.NetworkSubtype on line 68 (I can't figure out how to link it, sorry). I didn't love having two of these, so maybe it does make sense to combine them. It was simply a daunting task to figure out a list for everything. I'll do a little further research and revisit this |
||
| '3G', | ||
| '4G', | ||
| '5G' | ||
| ] | ||
| description: Type of cellular network that is currently in-use. | ||
| comment: There are a lot of subtypes that fall under the general '~G' types, but these aren't expanded upon here. | ||
|
|
||
| Cellular.Carrier: | ||
| datatype: string | ||
| type: sensor | ||
| description: Carrier that is currently in-use. | ||
|
|
||
| Cellular.DataUsage: | ||
| type: branch | ||
| description: Information on cellular data usage. | ||
|
|
||
| Cellular.DataUsage.Limit: | ||
| type: attribute | ||
| unit: MiB | ||
| datatype: uint32 | ||
| min: 0 | ||
| description: Data usage limit in megabytes. | ||
|
|
||
| Cellular.DataUsage.Current: | ||
| type: sensor | ||
| unit: MiB | ||
| datatype: uint32 | ||
| min: 0 | ||
| description: Amount of data used this cycle. | ||
|
|
||
| Cellular.DataUsage.CycleLength: | ||
| type: attribute | ||
| unit: day | ||
| datatype: uint16 | ||
| min: 0 | ||
| description: Length of a data cycle. | ||
| comment: Defines the period where the current data usage is relevant. | ||
|
|
||
| Cellular.DataUsage.CycleStart: | ||
| type: attribute | ||
| unit: iso8601 | ||
| datatype: string | ||
| min: 0 | ||
| description: Time the current data cycle started at. | ||
|
|
||
| WLAN: | ||
| type: branch | ||
| description: Properties related to WiFi connectivity. | ||
|
|
||
| WLAN.SignalStrength: | ||
| type: sensor | ||
| datatype: int8 | ||
| unit: dBm | ||
| max: 0 | ||
| description: WiFi connectivity signal strength. | ||
|
|
||
| WLAN.SignalStrength.Relative: | ||
| type: sensor | ||
| datatype: uint8 | ||
| unit: percent | ||
| min: 0 | ||
| max: 100 | ||
| description: WiFi connectivity signal strength in percent. | ||
|
|
||
| WLAN.SSID: | ||
| type: sensor | ||
| datatype: string | ||
| description: SSID of connected WiFi network. | ||
|
|
||
| WLAN.NetworkType: | ||
| datatype: string[] | ||
| type: sensor | ||
| allowed: [ | ||
| '0', | ||
| '1', | ||
| '2', | ||
| '3', | ||
| '4', | ||
| '5', | ||
| '6', | ||
| '6e', | ||
| '7' | ||
| ] | ||
| description: Type of WiFi network that is currently in-use. | ||
| comment: Defined as IEEE 802.11 generations, see https://en.wikipedia.org/wiki/Template:Wi-Fi_generations. | ||
|
|
||
| WLAN.IsMetered: | ||
| datatype: boolean | ||
| type: sensor | ||
| description: Indicates if the WiFi connectivity is metered. | ||
| True = Metered. False = Not metered. | ||
| comment: This signal can be used by onboard vehicle services to limit features such as background update downloads when on metered networks. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an overall CurrentDownload and CurrentUpload, with the understanding that this would simply correspond to whatever ConnectivityType is in-use. This may not work if for some reason cellular and WiFi were blended, but this scenario is relatively complex so I wasn't sure if it was worth considering over a more simplistic model.