[Solved] Issue with deviceId and last received data point


#1

I’m having an issue in several Data Tables that are set to use the last received data point. I have table listing several devices with their last reported signal strength, and a “device name” column with a link that looks like the following:

[{{format value}}](?ctx[currentDevice]={{deviceId}})

Until recently, this would send the user to the same dashboard but with the context variable for the current device’s ID set to the deviceId of that row’s device. However, now it just uses the default value for the dashboard.

Possibly related to this, the headers on a Data Table with one row are not showing up anymore:


#2

The issue is because of some changes we made in the routing mechanism within the app to make for cleaner URLs. If you watch your URL bar when you click the link, you’ll see that the page actually redirects to https://app.losant.com?ctx=...; then, the app catches that and redirects to your most recent dashboard, which happens to be the dashboard on which you’re seeing the problem.

To get around the issue you’re having, we introduced a {{dashboardUrl}} Handlebars helper so you can maintain functionality of the link along with the snappiness of the transition.

In your case, change your link from …

[{{format value}}](?ctx[currentDevice]={{deviceId}})

… to …

[{{format value}}]({{dashboardUrl ctx=(obj currentDevice=deviceId)}})

Let us know if you have any other issues!


#3

Yep, that seems to fix the context variable issue, thanks.

Any info on the missing headers on the Data Table? Sorry I included two different issues in one post, I thought maybe they were related.


#4

The missing headers were a design decision to make better use of the space in smaller blocks; if you add a little height to that block you will see the headers return.

I can see how removing the headers would be undesirable in the example you posted as you only have one row of data, but most of our data table users have enough rows to cause the block to scroll internally. Our thinking was, if a block is being dropped to such a small size that only a couple rows of data would be visible at a time, we were better off displaying more data and letting the table values speak for themselves as to what they represent.


#5

Ah I see that now, we have the table right at the size where the headers disappear. We’re trying to compare two sets of similar data - configuration settings on a device vs the cloud - so having them in two tables positioned one on top of the other seemed like the best way to compactly display these values. Is there a different widget that would work better for this? We considered using individual Gauge blocks but they take up a lot of space since we have 7 columns currently and will probably end up with around a dozen or so.


#6

We’re considering adding a rule where the header displays if the data set is small (e.g. 10 rows or fewer). Would that solve your individual case? I don’t know how many rows you typically have in each of those tables.


#7

Yes that would work for us. There will only be 1 row in each table


#8

We just released an update to the dashboard block tables; if the table contains 5 or fewer rows of data, the header will always display.