Re write sensors page as text rather than table

[TomBrien]

The sensors doc looks bad on mobile devices (see below) since the table is too wide for a screen. We should re write this plain text with each sensor as a sub-section heading to allow for easy direct linking. I'm thinking something like how configuration variables are shown in the main docs, see here for example.

Current page in Safari on a iPhone Xs:

And in Chrome on a Galaxy S10:

[dshokouhi]

You bring up a good point on this. In fact some of the sensors already exist as a sub-section so we may just need to flesh them out a bit more and remove from the table.

[jonasCr]

Hi,
I would love to contribute in this issue (as my first contribution ever ;) ). I know it's a bit old but still not fixed. Is it still open ? What is the expected result ?
Thanks for your help

[TomBrien]

Hi @jonasCr. Yep this is still very much open and help would be hugely appreciated 😄 . Currently the table has most sensors just listed in a table with the description also in the table. This really doesn't work in mobile browsers (see above). Instead I think we want remove the tables and translate the information in to paragraph form. Trying to combine the Android and iOS information where they are common and also incorporate the additional information from the bottom of the page. Something like (images may look poor on GitHub dark mode as we don't have the CSS we use on the actual site) also note I've fixed the previously incorrect entity ID.

Activity Sensor

Entity: sensor.<DEVICE_NAME>_activity
Platform: ,
Attributes iOS: confidence, types
Attributes Android: confidence
Description: The current activity type as computed by your device's OS. Requires motion permissions to be enabled.

Additional Details

sensor.activity provides the current motion activity as calculated by iOS along with the confidence of the calculations. Activities known by iOS and given by sensor.activity are:

• Stationary
• Walking
• Running
• Automotive
• Cycling

If iOS is unable to calculate an activity from motion data, Unknown will be given.

It is possible for multiple activities to be returned, such as Cycling and Stationary (if you are cycling but at a stop light), the state of the sensor is simply the first of these return by iOS (not necessarily the most likely). A complete list of calculated activities is given by the types attribute. See this post by @Mattt over at nshipster for a description of how different scenarios yield multiple activities.

The confidence attribute corresponds how accurate iOS believes the report of the current activity is. Possible values are:

• Low
• Medium
• High

This sensor is only available on the full flavor of the Android app that is found in the Google Play Store, it is not available for the minimal flavor. For android the user will have a different set of states to go by:

• in_vehicle
• on_bicycle
• on_foot
• running
• still
• tilting
• walking
• unknown

The attribute for the state will reflect the confidence rating from the Activity Recognition API. This sensor requires the Activity Recognition permission.

[jonasCr]

Thanks for your answer. I think I will have a few times those days to get into this. Tell me if I'm wrong but the main idea is:

1. Drop the tables of the doc pages
2. Replace the information of the tables in paragraph with both iOs and Android information
3. Add the content of the actual paragraph, if exist, in a new Additional details section

Am I going in the right direction ?

[TomBrien]

Yep that sounds pretty much right. Thanks again :)