/*
* Handover query to some external SF OData Service to fecth the requested data
*/
srv.on("READ", Whatever, async req => {
const sf_api_def = cds.env.requires['sfsf'] //defined in package.json
sf_api_def.credentials.destination = "myDestinationName" //set your Destination name, could come from a customizing table
const sfsfSrv = await cds.connect.to(sf_api_def)
return await sfsfSrv.run(req.query)
})
But all this didn’t help me to complete the task. Got the solution which finally worked for me from this SAP Sample Susaas (two snippets: here and here).
server.js
const cds = require("@sap/cds")
cds.on('served', async () => {
const { 'cds.xt.SaasProvisioningService': provisioning } = cds.services
// Add provisioning logic only if multitenancy is there..
if (provisioning) {
let tenantProvisioning = require('./provisioning')
provisioning.prepend(tenantProvisioning)
} else {
console.log(">>> There is no service, therefore does not serve multitenancy!")
}
})
module.exports = cds.server
Prerequisite, you have registered an SAP SuccessFactors system in your Global Account (see here). Creating the sap-successfactors-extensibility service can be done via command line:
#Created the service instance
#An HTTP destination on a subaccount level with the same name as the service instance name is automatically generated
cf create-service sap-successfactors-extensibility api-access myInstanceName -c '{"systemName": "SFCPART000000","technicalUser": "sfadmin"}'
#Bind the instance to an application
cf bind-service myApp-srv myInstanceName
a separate OAuth2 client application on SFSF side (can find in SF in Manage OAuth2 Client Applications)
a separate destination definition on a BTP sub-account level
The technicalUser parameter can be specified only during creation. There is no possibility to provide it afterwards using cf update-service. It may be possible to manually update the technicalUser in the destination, which got automatically created. But I did not test this yet.
Of course, the same service creation can also be done via mta.yaml.
resources:
#####################################################################################################################
# SuccessFactors Extensibility Service
#####################################################################################################################
- name: myInstanceName
type: org.cloudfoundry.managed-service
#type: org.cloudfoundry.existing-service
parameters:
service: sap-successfactors-extensibility
service-plan: api-access
config:
systemName: SFCPART000000 # <-- Provide your system name
technicalUser: sfadmin
For initial deployment, you need the line type: org.cloudfoundry.managed-service. For all further deployments, you have to comment that line out and comment in the next line type: org.cloudfoundry.existing-service. Else you will receive an error. Read more about that behavior here:https://github.com/SAP-samples/successfactors-extension-calculate-employee-seniority/issues/2
Vor kurzem haben wir uns eine Klimaanlage zugelegt. Diese nutzen wir zum Heizen und Kühlen unseres Büros. Dabei handelt es sich um dieses Gerät der Marke Midea (in DE vor allem als Comfee vermarktet).
Der schlimmste Teil der Installation war wie so häufig nicht die Montage, sondern die Einrichtung des Innengerätes über die App. Um das Gerät in das lokale Wifi zu bringen, muss man sich mit einem Access Point des Gerätes verbinden und dann in der App eine Einrichtung durchlaufen. Nach mehreren gescheiterten Versuchen mit einem Android Telefon, habe ich dann zu einem iPhone gegriffen. Hiermit klappte die Einrichtung erheblich besser! Obwohl das Gerät dann im lokalen Netz erreichbar ist, erfolgt die Steuerung dann über eine Cloud… mit entsprechend langsamen Reaktionszeiten. Meiner Meinung nach quasi unbenutzbar.
Um das Gerät ohne großes manuelles Zutun betreiben zu können (also ohne App oder Fernbindung), habe ich daher nach einer entsprechenden Home Assistant Integration gesucht.
So ganz habe ich dabei nicht verstanden, ob die Integration nun lokal oder via der Cloud steuert. Zumindest musste man beim Einrichtung seine Cloud Zugangsdaten angeben und darüber wird dann das lokale Gerät ermittelt. Beim Testen fiel mir auf, dass sobald man diese Integration nutzte, das Gerät nicht mehr über die App steuerbar war (und umgekehrt). Der Grund ist, dass man den gleichen Zugang nicht auf zwei verschiedenen Geräten nutzen kann. Nach einer Einrichtung eines zweiten Accounts trat das Problem nicht mehr auf und man konnte beides parallel nutzen.
So richtig zuverlässig funktionierte das Ein- oder Ausschalten des Gerätes bei mir jedoch nicht. Ggf. weil die Befehle auch über die Cloud liefen und nicht lokal!?
Auch die Entities der Integration schienen für die Klimaanlage nicht vollständig zu sein. Insgesamt schien die Integration eher für anderen Midea Gerätetypen geeignet zu sein, als Klimaanlagen.
Die Integration bietet die Möglichkeit, selber die entsprechen Sensoren und Controls zu aktivieren. Man muss also durch Trial-and-Error herausfinden, welche von dem eigenen Gerät unterstützt bzw. publiziert werden
oder in den Developer Tools nach der zugehörigen Climate Entity suchen und sich die Werte anschauen.
Nach etwas herumprobieren, bin ich bei dieser Auswahl geblieben.
Leider funktioniert die Realtime Power nicht, aber immerhin der Gesamtverbrauch. Ich habe daher noch eine Zigbee Steckdose mit Strommessung davor geschaltet, um den Verbrauch in Echtzeit zu überwachen. Außerdem konnte ich die Indoor und OutdoorTemperature Werte noch nicht wirklich nachvollziehen. Sie verändern sich m.M.n. recht merkwürdig. In der vorherigen Integration wurden hier irgendwie genauere Werte angezeigt. Jemand hat dazu auch bereits ein Issue aufgemacht.
Eine entsprechende Thermostat Card wird auch direkt auf dem Dashboard erzeugt.
Der wirklich interessante Teil ist dann natürlich erst durch Automationen zu verwirklichen. Ich lasse die Klimaanlage z.B. automatisiert bei entsprechenden Uhrzeiten und Temperaturen einschalten. Oder auch, wenn z.B. grade ausreichend Strom von dem Balkonkraftwerk erzeugt wird. Und natürlich wird sie automatisch ausgeschaltet, wenn alle das Haus verlassen.
Insgesamt funktioniert die Integration nun seit einigen Wochen sehr zuverlässig.
Update 08.07.2024: In diesen Reddit Thread wird mehrfach erwähnt, dass man ggf. auch den Wi-Fi-Stick mit einer ESP basierten Lösung ersetzten kann, wie z.B. dieser hier. Das werde ich aber erst testen, wenn es mit der aktuellen Lösung zu Problemen kommt.
When I was at a friend’s house the other day and a YouTube playlist was playing on the TV, I was really shocked. After every video, there were one or two ads (and some of them even in between). I was not aware how extremely many ads you get when using YouTube without an ad blocker. Therefore, a small collection of apps, add-ons and links that help to make YouTube a bit more enjoyable:
Browser
uBlock Origin: Add-on which blocks ads, trackers and malware sites
Update 15.01.2024: When using YouTube in a Browser in combination with uBlock, you likely receive the following message right now: “Ad blockers are not allowed on YouTube”. The only working solutions to prevent this message and to continue watching ad -free is disabling uBlock on YouTube and use this Script with Tampermonkey (at least for me).
