PowerShell based cmdlets / Commands

[c8h10n4o2]

So... I hope I've found and fixed the issue with the Connect-TelldusLive cmdlet.

Could you update the module to version 1.1.3 and try again?

You should be able to just run the cmdlet to connect, it should detect the login automatically within 30 seconds or so and it should ”just work” after that.

[Masonit]

After updated to lastest it works now!

When connecting I connect with: Connect-TelldusLive -UseSavedCredential
It works, is this the "right" way?

\Masonit

[c8h10n4o2]

Awesome!

Glad to hear it works now.

Yes, you are exactly right. First time you use the module on a computer you run:
Connect-TelldusLive -SaveCredential

Then authenticate the module through the Telldus website. After that, you can simply run:
Connect-TelldusLive -UseSavedCredential

And the access token you retrieved in the first step will be reloaded without having to go through the Telldus website again. This is how I use it myself


Sidenote: The accesstoken is stored encrypted on the computer, it get's encrypted using your current user session so only the user who ran the command will be able to use it (for obvious security reasons). Can be good to know if you want to run scheduled tasks etc, that will work just fine but you need to run it under the same user account.

The module actually have a cmdlet for exporting the access token if you need to (Get-TDAccessToken) but I don't imagine anyone having that much use for it, "Connect-TelldusLive -UseSavedCredential" is the preferred way

[c8h10n4o2]

Just wanted to mention that the module has been updated to version 1.1.4 now. Added some validation that the saved/specified credentials actually work when executing the Connect-TelldusLive cmdlet, and I've also made some improvements on the backend service, error messages should now hopefully be at least a little bit better and help when troubleshooting is needed.

And just because it's possible for pocket money... the backend service supporting this module is now geo-redundant (supported by two different Azure regions, North and West Europe) with automatic failover and scaling in each region.

So hopefully it should be fairly reliable as well

Version 1.1.5 is available at https://www.powershellgallery.com/packa ... maTD/1.1.5 (or just run "Update-Module AutomaTD" in a PowerShell prompt if you already installed it earlier, or "Install-Module AutomaTD" if you haven't used it before).

If anything seems weird, please ping me so I can get it fixed!

[c8h10n4o2]

Seems you are right @ArneG, I get the same behavior (and now I can't get my sensor back! )

I know that this has worked fine in the past, and as you say, the Telldus Live! website is broken in the same way, so seems this is a problem on their end. I'll add a support ticket to them asking about it.

Not sure if this is valid workaround for you in the meantime, but if you update to the latest version of the module (1.1.5, available at: https://www.powershellgallery.com/packa ... maTD/1.1.5), you can run:
$SensorData=Get-TDSensor -IncludeIgnored | Get-TDSensorData

To fetch data for ignored/hidden sensors as well. The switch was actually available in earlier versions of the module, but sadly there was a bug so it didn't work.

Should work fine now though!

Thanks for reporting the issue!

[c8h10n4o2]

Ah, OK. Seems they have no plans to fix it?

Oh well, at least it's fixable by them manually then. Thanks for reporting back!

[c8h10n4o2]

Roger that!

[c8h10n4o2]

Sorry for my late reply, somehow I didn't get any notification about your post, so I just noticed it now.

Anyway, I hope I've fixed that bug now, please update to version 1.1.6 and try again! (Update-Module AutomaTD -Force)

Thanks for reporting the bug!

[c8h10n4o2]

Doh!

Of course! Fixed in 1.1.7! Thanks again for reporting

[c8h10n4o2]

If you store the output from Get-TDSensorData and look in the data-property, do you see the values there?

For example:
$Sensor = Get-TDSensorData -DeviceID 123456789
$Sensor.Data

[c8h10n4o2]

Great!

Does that work for you?

[c8h10n4o2]

I guess that could make sense, I'll try to look into it when I get a chance!

Meanwhile, you could try this:

Code: Select all

$SensorData=Get-TDSensor | Get-TDSensorData
$SensorData | select *, @{N='RainRate';e={ $_.data.where({$_.name -eq 'rrate'}).value }}, @{N='RainTotal';e={ $_.data.where({$_.name -eq 'rtot'}).value }} | Export-Csv "Sensors.csv" -Encoding utf8

[c8h10n4o2]

I'm afraid not, looks like the module has to be updated to support that.

[c8h10n4o2]

@ArneG Could you try the latest version (1.2.0) and check if it now works as you expect?

Get-TDSensorData and Get-TDSensorHistoryData should now hopefully post all values from the sensors "out of the box"

[c8h10n4o2]

hmmm, I get what you mean but I think hardcoding the properties again is not a good approach for the module at least, as soon as someone buys another type of sensor it will be "broken" again, this problem is more related to exporting things to CSV instead of a format that handle different objects.

Actually, using the Select-Object method is probably the best way of doing this in any implementation.

That said, I'll do some thinking to see if I can maybe figure something out that will work for you... Hang on