PowerShell based cmdlets / Commands

[c8h10n4o2]

Probably because you're excluding sensors with those properties when you do that, if no sensor is reporting that type of sensor value, it wont be included in the results.

It will just make sure all objects have the same properties. I've done another update though (1.3.2), so now the ConvertTo-TDNormalizedOutput cmdlet has a "PropertiesToAlwaysInclude" parameter which should help you achieve that last use case.

Sample code:

Code: Select all

Get-TDSensor | Get-TDSensorData | ConvertTo-TDNormalizedOutput -PropertiesToAlwaysInclude RainRate, RainTotal, Temperature, Humidity

Hope that will help

[c8h10n4o2]

That's what I get for using native .net instead to enhance performance

It's case sensitive, so it didn't think Raintotal and RainTotal was the same thing.

Updated version with (hopefully) a fix uploaded, also added friendly names for what I think are the correct types for wind sensors.

Hope it will work without any issues now!

Thanks for testing these updates out btw

[c8h10n4o2]

It isn't included? If you refer to the actual code it's not in the list of "Friendly names" because it's already called Humidity in the API

[c8h10n4o2]

Just an FYI - I just upgraded to a TellStick ZNet Lite v2 and realized that no events are "migrated" during the switch, all are left broken.

I've written a PowerShell script that can automatically fix all events so they work again (update the sensors/devices in all events so they match the new ones that Telldus "copied" to the new Tellstick).

I used that script to migrate all of my events and it seems to work flawlessly. If anyone have plans of doing the same thing and want to be a beta tester just ping me and I'll help you out (the script has only been used once so I'd like to test it a bit more before I release it for anyone to use).


The most important thing is that you run Get-TDDevice and Get-TDSensor and store all of that data somewhere safe before you remove your old Tellstick! (for example using Export-Clixml or Export-Csv)

Basically need to build a list of deviceids that should be changed (translate old deviceid -> new deviceid).

[c8h10n4o2]

Ahh, thanks for reporting back! I've added a fix to the module for that but I'm working a few other changes as well so I'd rather wait and release them all at the same time. Not sure when I'll do the release but I'll post back when I do!

[c8h10n4o2]

So, I've published a new version (1.4.0) now which should change wgust to WindGust (sorry, I guess this will be a breaking change for you but I hope you can manage ).

I've also added a few new functions/cmdlets as well, one noteworthy function is "Backup-TDAccount" which will store information about the clients/locations, devices, sensors, schedules and events that are associated with Telldus Live! account on local disk. This backup can be used to for example restore events in case they got lost, or as in my case, be used to migrate events from one client (Tellstick) to another (used it when I migrated from Tellstick Net to TellStick ZNet Lite v2).

The actual migration script is not published yet, but if anyone has need for it please ping me and we'll work something out!

[c8h10n4o2]

Minor update, seems there have been some intermittent connection issues against the Telldus Live! API lately, I've therefor added "server side retries", ie. the backend service used by the module will automatically perform a few retries (for errors related to the specific connection issues) before giving up.

This could potentially cause a slight delay in the response, but will hopefully improve reliability of the module even when Telldus Live! is a bit shaky

Related error message you might have seen in the module:
Telldus Live! API responded with error: "Unable to connect to the remote server"

If you still see this message or something similar, please respond to this thread with the exact error and I'll have a look.

[c8h10n4o2]

Awesome! Happy to hear that.

I don't think it has been fixed on the Telldus Live side, the app is logging an event every time this happens and it happened quite a few times yesterday as well. Nothing so far today though, but it seems to come in "bursts", where multiple timeouts and connection failures happens within a specific time window.

Anyway, hope this change can fix that at least to some level so it becomes less of a problem from a module usage standpoint

[Masonit]

Hi

Just upgraded to Znet v2 and AutomaTD 1.4.

Looking forward to more reliable state value from z-wave device. But does not seem to be able to query the state of z-wave device. Should I just trust the state value I get from get-tddevice? I know this value can't be trusted on 433 devices because of one way communication.

\Masonit

[c8h10n4o2]

Hmm... That seems weird. What do you mean by not being able to query the state value? Is the value wrong, missing or something else?

The module just gets the data from the Telldus API, hopefully that should be correct. But if not, I'll be happy to take a closer look on what's up!

(I actually don't have any z wave device yet though but we'll figure something out!)

[Masonit]

I just thought I should be able to run a commad and refresh status for a specific device. The refresh command would query the physical device status.
But I just did some testing and turned off and turned on the z-wave device on the physical on/off button. And status in telldus live is updated correctly. Seems like state on z-wave device is trustworth in Tellus live.

\Masonit

[c8h10n4o2]

Ahh, I get what you mean now.

Just as you said, I guess the status in Telldus Live! is simply kept in sync/updated on an event basis. So as long as the internet connection isn't dropped or there is a service error or similar, the status should be trustworthy I guess

Glad it works

[c8h10n4o2]

I was just made aware of a problem with authenticating this module when it's used initially or without using a stored credential that sadly seems to have been going on for a while, my apologies to anyone who's been affected by this (I used a service to provide shortened urls that was depricated this spring).

It should now have been fixed, so if you've experienced an issue related to this, please try again now!

[c8h10n4o2]

Just wanted to let you know that I've upgraded the "backend part" to newer infrastructure. Shouldn't make any difference whatsoever in terms of how to use the module etc. but hopefully it will be slightly faster now

If you notice something weird then please reach out and I'll have a look ASAP.

[Masonit]

Great that you still are maintaining the cmdlets!

Regarding my worries for unrelyable status on znet devices. My worries was not wrong.
I made some testing with znet device that was almost out of range. Often when I send on to the device. The physical device was turned on and status was set to on in telldus live. But some seconds later the status was automatically set to off again in telldus live. Under device history you could then see that the status change was discarded because verification was never received from znet device. This resulted in znet device turned on and status as off in telldus live. I guess this is something that can never be 100%. But it would be good to be able to request status directly from znet device or trigger a status update in telldus live as I thought was possible in the beginning.

But I guess I could always double check device history for any errors.

\Masonit