I've just soldered all my stuff together, just wondering where I can get some help about the Nanode?
In the setup I've put in some traces:
ethernet_setup(mac,ip,gateway,server,80,8); // Last two: PORT and SPI PIN: 8 for Nanode, 10 for nuelectronics
Serial.println("Ethernet set up");
rf12_initialize(MYNODE, freq,group);
Serial.println("RF12 Initialized");
But almost always I can't get the trace for 'RF12 Initialized'? I've cut the 5V pin from the RFM12B, but do I have to remove the other components as well as shown in this pic: http://wiki.hackspace.org.uk/wiki/File:JeeNode_RFM12B.jpg
As I've already soldered them on, and finding it difficult to remove them!
Is there some way to get some more debug info from the rf12_initialize command?
Regards,
Reuben
Re: Nanode + RFM12B can't initialise
Hi Reuben,
There is an error in the Nanod 5 board which stops the RFM12B and Ethernet being used at the same time. Have you followed the instructions here to mod the board?
http://wiki.hackspace.org.uk/wiki/Project:Nanode/Applications#RFM12_Wireless_Module
What sketch are you trying to run?
All the best, Glyn.
Re: Nanode + RFM12B can't initialise
Yes I followed the instructions from that post. I've removed the 10k resistor, and bent up pin 4. However I just cut the 5V header pin, I didn't remove all the components as shown in the picture, but that should be ok
(For connecting to the nanode there is no need to solder in the 3.3V voltage regulator. Just omit the 5V headder pin. The RFM12B will get is 3.3V power from the Nanode's 3.3V voltage regulator.)
I'm trying to run EtherShield_simpleClient_Pachube_RF12 from https://github.com/openenergymonitor/sketchbook/tree/master/EtherShield_...
Re: Nanode + RFM12B can't initialise
I think I know what the problem is. The RFM12 board needs to be plugged into a special port an the Nanode. This requires an extra header to be soldered in. Quite a few people have been having this problem. I will update the Nanode RFM12B section of the London hackspace wiki as soon as I get a chance. For now see image below:
Had you plugged the RFM12 board into the wrong port on the Nanode? Has this fixed the problem?
Re: Nanode + RFM12B can't initialise
Ah so this is a different port to the pins just below? I thought they were.joined but it seems not, I'll try tonight and update on success or.not
Re: Nanode + RFM12B can't initialise
Yes their different. Just updated the Nanode wiki with image showing location of RFM12B wireless port: http://wiki.hackspace.org.uk/wiki/Project:Nanode/Applications#RFM12_Wireless_Module
Re: Nanode + RFM12B can't initialise
Thanks Glyn, working now!! Also on the wiki you say an extra 9 pin header is needed? But the pin next to the 3V3 is Dig7 from this pic: http://wiki.hackspace.org.uk/wiki/File:Nanode_conns.jpg
Where is that supposed to connect to the RFM12B? Or you are just unable to use this pin with the RFM12B?
I also have a question about sending the data to Pachube. I've put in a delay of 30seconds, as I haven't got the pro account yet, but I don't get any response from Pachube when I do this, can you see if there's any error in my code? If I get rid of the lines I added, it will update a few values, but then get the error that I'm exceeding the limit.
I've only added 'lastUpdate', but the println(sent) statement works, but just doesn't seem to send the data!?!
#include <Ports.h>
#include <RF12.h>
#define MYNODE 30 //node ID 30 reserved for base station
#define freq RF12_433MHZ //frequency
#define group 212 //network group
#include <EtherShield.h>
byte mac[6] = {
0x54,0x55,0x38,0x12,0x01,0x23};
byte ip[4] = {
192,168,1,131};
byte gateway[4] = {
192,168,1,1};
byte server[4] = {
173,203,98,29};
#define PACHUBE_VHOST "www.pachube.com"
#define PACHUBEAPIKEY "www.pachube.com\r\nX-PachubeApiKey: xxxxxxxxxxxxxxx"
#define PACHUBEAPIURL "/api/xxx.csv"
char str[150];
int dataReady=0;
unsigned long lastUpdate; // only update every 5 seconds
//########################################################################################################################
// EmonTX Data Structure to be received
//########################################################################################################################
typedef struct {
int ct1; // current transformer 1
int ct2; // current transformer 2
int nPulse; // number of pulses recieved since last update
int temp1; // One-wire temperature 1
int temp2; // One-wire temperature 2
int temp3; // One-wire temperature 3
int supplyV; // emontx voltage
}
Payload;
Payload emontx;
int emontx_nodeID; //node ID of emon tx, extracted from RF datapacket. Not transmitted as part of structure
//########################################################################################################################
void setup()
{
Serial.begin(9600);
Serial.println("EtherShield_simpleClient_Pachube_RF12");
ethernet_setup(mac,ip,gateway,server,80,8); // Last two: PORT and SPI PIN: 8 for Nanode, 10 for nuelectronics
Serial.println("Ethernet set up");
rf12_initialize(MYNODE, freq,group);
Serial.println("RF12 Initialized");
lastUpdate = millis();
}
void loop()
{
//----------------------------------------
// 1) Recieve data from rf12
//----------------------------------------
if (rf12_recvDone() && rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0 && rf12_len==sizeof(Payload) )
{
emontx=*(Payload*) rf12_data;
emontx_nodeID=rf12_hdr & 0x1F; //extract node ID from received packet
Serial.print("Node ID: ");
Serial.println(emontx_nodeID);
// Construct CSV
Serial.println("CSV:");
sprintf(str,"%d",emontx.ct1);
Serial.println(str);
dataReady = 1;
}
//----------------------------------------
// 2) Send the data (wait every 30 seconds)
//----------------------------------------
if ((millis()-lastUpdate)>30000)
{
lastUpdate = millis();
if (ethernet_ready() && dataReady==1)
{
ethernet_send_post(PSTR(PACHUBEAPIURL),PSTR(PACHUBE_VHOST),PSTR(PACHUBEAPIKEY), PSTR("PUT "),str);
Serial.println("sent");
dataReady = 0;
}
}
}
Re: Nanode + RFM12B can't initialise
Fantastic.
Well spotted, your right, it's only 8 pins. Dig 7 is not used by the RFM12. I'll update the wiki. Thanks for spotting that.
I'v heard that Pachube have changed their API since we made that example. Iv not really used Pachube myself, I've been using emoncms. I know a couple of people are looking to re-write the example. In the meantime here is a link to an example of posting data to Pachube. I havent tested it myself but it was posted up by Pachube on their twitter, so I would assume it works. It used the Ethercard library from JeeLabs rather than the Ethershield library from Andy (cofusing I know!). Download it here
Let me know how you get on.
Good luck, Glyn.


Network Working Group G. Zorn Request for Comments: 2868 Cisco Systems, Inc. Updates: RFC 2865 D. Leifer Category: Informational A. Rubens Ascend Communications J. Shriver Intel Corporation M. Holdrege ipVerse I. Goyret Lucent Technologies June 2000 RADIUS Attributes for Tunnel Protocol Support Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks.1. Motivation
Many applications of tunneling protocols such as L2TP involve dial-up network access. Some, such as the provision of access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, new RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points; this document defines those attributes. Specific recommendations for, and examples of, the application of these attributes for L2TP can be found in RFC 2809. Zorn, et al. Informational [Page 1] RFC 2868 RADIUS Tunnel Authentication Attributes June 20002. Specification of Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [14].3. Attributes
Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields; otherwise, the Tag field SHOULD NOT be used. If the RADIUS server returns attributes describing multiple tunnels then the tunnels SHOULD be interpreted by the tunnel initiator as alternatives and the server SHOULD include an instance of the Tunnel-Preference Attribute in the set of Attributes pertaining to each alternative tunnel. Similarly, if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute.3.1. Tunnel-Type
Description This Attribute indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the tunnel end-point; the RADIUS server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an Access-Reject had been received instead. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the RADIUS server determines that the use of the communicated protocol is not authorized, it MAY return an Access-Reject packet. If a tunnel terminator receives an Access-Accept packet which contains Zorn, et al. Informational [Page 2] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 one or more Tunnel-Type Attributes, none of which represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an Access-Reject had been received instead. A summary of the Tunnel-Type Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Tunnel-Type Length Always 6. Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started. 1 Point-to-Point Tunneling Protocol (PPTP) [1] 2 Layer Two Forwarding (L2F) [2] 3 Layer Two Tunneling Protocol (L2TP) [3] 4 Ascend Tunnel Management Protocol (ATMP) [4] 5 Virtual Tunneling Protocol (VTP) 6 IP Authentication Header in the Tunnel-mode (AH) [5] 7 IP-in-IP Encapsulation (IP-IP) [6] 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 10 Generic Route Encapsulation (GRE) [9] 11 Bay Dial Virtual Services (DVS) 12 IP-in-IP Tunneling [10] Zorn, et al. Informational [Page 3] RFC 2868 RADIUS Tunnel Authentication Attributes June 20003.2. Tunnel-Medium-Type
Description The Tunnel-Medium-Type Attribute indicates which transport medium to use when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. It MAY be included in both Access-Request and Access-Accept packets; if it is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnel media supported by the tunnel end- point. The RADIUS server MAY ignore the hint, however. A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 for Tunnel-Medium-Type Length 6 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets and contains one of the values listed under "Address Family Numbers" in [14]. For the sake of convenience, a relevant excerpt of this list is reproduced below. 1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Relay, ATM) Zorn, et al. Informational [Page 4] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress3.3. Tunnel-Client-Endpoint
Description This Attribute contains the address of the initiator end of the tunnel. It MAY be included in both Access-Request and Access- Accept packets to indicate the address from which a new tunnel is to be initiated. If the Tunnel-Client-Endpoint Attribute is included in an Access-Request packet, the RADIUS server should take the value as a hint; the server is not obligated to honor the hint, however. This Attribute SHOULD be included in Accounting- Request packets which contain Acct-Status-Type attributes with values of either Start or Stop, in which case it indicates the address from which the tunnel was initiated. This Attribute, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. A summary of the Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 66 for Tunnel-Client-Endpoint. Length >= 3 Zorn, et al. Informational [Page 5] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use.3.4. Tunnel-Server-Endpoint
Description This Attribute indicates the address of the server end of the tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if the initiation of a tunnel is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. This Attribute, along with the Tunnel-Client-Endpoint and Acct- Tunnel-Connection-ID Attributes [11], may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. Zorn, et al. Informational [Page 6] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 for Tunnel-Server-Endpoint. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [17]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use. Zorn, et al. Informational [Page 7] RFC 2868 RADIUS Tunnel Authentication Attributes June 20003.5. Tunnel-Password
Description This Attribute may contain a password to be used to authenticate to a remote server. It may only be included in an Access-Accept packet. A summary of the Tunnel-Password Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Salt (cont) | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 69 for Tunnel-Password Length >= 5 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, the Tag field SHOULD be ignored. Salt The Salt field is two octets in length and is used to ensure the uniqueness of the encryption key used to encrypt each instance of the Tunnel-Password attribute occurring in a given Access-Accept packet. The most significant bit (leftmost) of the Salt field MUST be set (1). The contents of each Salt field in a given Access-Accept packet MUST be unique. String The plaintext String field consists of three logical sub-fields: the Data-Length and Password sub-fields (both of which are required), and the optional Padding sub-field. The Data-Length sub-field is one octet in length and contains the length of the unencrypted Password sub-field. The Password sub-field contains Zorn, et al. Informational [Page 8] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 the actual tunnel password. If the combined length (in octets) of the unencrypted Data-Length and Password sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. If it is present, the length of the Padding sub-field is variable, between 1 and 15 octets. The String field MUST be encrypted as follows, prior to transmission: Construct a plaintext version of the String field by concatenating the Data-Length and Password sub-fields. If necessary, pad the resulting string until its length (in octets) is an even multiple of 16. It is recommended that zero octets (0x00) be used for padding. Call this plaintext P. Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) The resulting encrypted String field will contain c(1)+c(2)+...+c(i). On receipt, the process is reversed to yield the plaintext String.3.6. Tunnel-Private-Group-ID
Description This Attribute indicates the group ID for a particular tunneled session. The Tunnel-Private-Group-ID Attribute MAY be included in the Access-Request packet if the tunnel initiator can pre- determine the group resulting from a particular connection and SHOULD be included in the Access-Accept packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a Zorn, et al. Informational [Page 9] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 particular interface. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. A summary of the Tunnel-Private-Group-ID Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 81 for Tunnel-Private-Group-ID. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs.3.7. Tunnel-Assignment-ID
Description This Attribute is used to indicate to the tunnel initiator the particular tunnel to which a session is to be assigned. Some tunneling protocols, such as PPTP and L2TP, allow for sessions between the same two tunnel endpoints to be multiplexed over the same tunnel and also for a given session to utilize its own dedicated tunnel. This attribute provides a mechanism for RADIUS to be used to inform the tunnel initiator (e.g. PAC, LAC) whether to assign the session to a multiplexed tunnel or to a separate tunnel. Furthermore, it allows for sessions sharing multiplexed tunnels to be assigned to different multiplexed tunnels. Zorn, et al. Informational [Page 10] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 A particular tunneling implementation may assign differing characteristics to particular tunnels. For example, different tunnels may be assigned different QOS parameters. Such tunnels may be used to carry either individual or multiple sessions. The Tunnel-Assignment-ID attribute thus allows the RADIUS server to indicate that a particular session is to be assigned to a tunnel that provides an appropriate level of service. It is expected that any QOS-related RADIUS tunneling attributes defined in the future that accompany this attribute will be associated by the tunnel initiator with the ID given by this attribute. In the meantime, any semantic given to a particular ID string is a matter left to local configuration in the tunnel initiator. The Tunnel-Assignment-ID attribute is of significance only to RADIUS and the tunnel initiator. The ID it specifies is intended to be of only local use to RADIUS and the tunnel initiator. The ID assigned by the tunnel initiator is not conveyed to the tunnel peer. This attribute MAY be included in the Access-Accept. The tunnel initiator receiving this attribute MAY choose to ignore it and assign the session to an arbitrary multiplexed or non-multiplexed tunnel between the desired endpoints. This attribute SHOULD also be included in Accounting-Request packets which contain Acct- Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, then it should assign a session to a tunnel in the following manner: If this attribute is present and a tunnel exists between the specified endpoints with the specified ID, then the session should be assigned to that tunnel. If this attribute is present and no tunnel exists between the specified endpoints with the specified ID, then a new tunnel should be established for the session and the specified ID should be associated with the new tunnel. If this attribute is not present, then the session is assigned to an unnamed tunnel. If an unnamed tunnel does not yet exist between the specified endpoints then it is established and used for this and subsequent sessions established without the Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-ID Attribute was not specified to a named tunnel (i.e. one that was initiated by a session specifying this attribute). Zorn, et al. Informational [Page 11] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 Note that the same ID may be used to name different tunnels if such tunnels are between different endpoints. A summary of the Tunnel-Assignment-ID Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 82 for Tunnel-Assignment-ID. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String This field must be present. The tunnel ID is represented by the String field. There is no restriction on the format of the ID.3.8. Tunnel-Preference
Description If more than one set of tunneling attributes is returned by the RADIUS server to the tunnel initiator, this Attribute SHOULD be included in each set to indicate the relative preference assigned to each tunnel. For example, suppose that Attributes describing two tunnels are returned by the server, one with a Tunnel-Type of PPTP and the other with a Tunnel-Type of L2TP. If the tunnel initiator supports only one of the Tunnel-Types returned, it will initiate a tunnel of that type. If, however, it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference Attribute to decide which tunnel should be started. The tunnel having the numerically lowest value in the Value field of this Attribute SHOULD be given the highest preference. The values assigned to two or more instances of the Tunnel-Preference Zorn, et al. Informational [Page 12] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 Attribute within a given Access-Accept packet MAY be identical. In this case, the tunnel initiator SHOULD use locally configured metrics to decide which set of attributes to use. This Attribute MAY be included (as a hint to the server) in Access-Request packets, but the RADIUS server is not required to honor this hint. A summary of the Tunnel-Preference Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 83 for Tunnel-Preference Length Always 6. Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). Value The Value field is three octets in length and indicates the preference to be given to the tunnel to which it refers; higher preference is given to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred.3.9. Tunnel-Client-Auth-ID
Description This Attribute specifies the name used by the tunnel initiator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. Zorn, et al. Informational [Page 13] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 90 for Tunnel-Client-Auth-ID. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String This field must be present. The String field contains the authentication name of the tunnel initiator. The authentication name SHOULD be represented in the UTF-8 charset.3.10. Tunnel-Server-Auth-ID
Description This Attribute specifies the name used by the tunnel terminator during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet, and MUST be included in the Access-Accept packet if an authentication name other than the default is desired. This Attribute SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are transmitted from left to right. Zorn, et al. Informational [Page 14] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 91 for Tunnel-Server-Auth-ID. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. String This field must be present. The String field contains the authentication name of the tunnel terminator. The authentication name SHOULD be represented in the UTF-8 charset.4. Table of Attributes
The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Acct-Request # Attribute 0+ 0+ 0 0 0-1 64 Tunnel-Type 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 0 0+ 0 0 0 69 Tunnel-Password 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 0+ 0+ 0 0 0 83 Tunnel-Preference 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. Zorn, et al. Informational [Page 15] RFC 2868 RADIUS Tunnel Authentication Attributes June 20005. Security Considerations
The Tunnel-Password Attribute may contain information which should only be known to a tunnel endpoint. However, the method used to hide the value of the attribute is such that intervening RADIUS proxies will have knowledge of the contents. For this reason, the Tunnel- Password Attribute SHOULD NOT be included in Access-Accept packets which may pass through (relatively) untrusted RADIUS proxies. In addition, the Tunnel-Password Attribute SHOULD NOT be returned to an unauthenticated client; if the corresponding Access-Request packet did not contain a verified instance of the Signature Attribute [15], the Access-Accept packet SHOULD NOT contain an instance of the Tunnel-Password Attribute. Tunnel protocols offer various levels of security, from none (e.g., PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory tunneling case any security measures in place only apply to traffic between the tunnel endpoints. In particular, end-users SHOULD NOT rely upon the security of the tunnel to protect their data; encryption and/or integrity protection of tunneled traffic MUST NOT be considered as a replacement for end-to-end security.6. IANA Considerations
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.6.1. Tunnel-Type
Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the remaining values are available for assignment by the IANA with IETF Consensus [16].6.2. Tunnel-Medium-Type
Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2; the remaining values are available for assignment by the IANA with IETF Consensus [16].7. References
[1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. Zorn, et al. Informational [Page 16] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 [2] Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998. [3] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999. [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997. [5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996. [8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995. [9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000. [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Zorn, et al. Informational [Page 17] RFC 2868 RADIUS Tunnel Authentication Attributes June 20008. Acknowledgements
Thanks to Dave Mitton for pointing out a nasty circular dependency in the original Tunnel-Password attribute definition and (in no particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and Bernard Aboba for useful input and review.9. Chair's Address
The RADIUS Working Group can be contacted via the current chair: Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588 Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Authors' Addresses
Questions about this memo can also be directed to: Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 USA Phone: +1<PHONE_NUMBER> FAX: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105 Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Zorn, et al. Informational [Page 18] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 John Shriver Intel Corporation 28 Crosby Drive Bedford, MA 01730 Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Allan Rubens Ascend Communications 1678 Broadway Ann Arbor, MI 48105 Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803 EMail<EMAIL_ADDRESS>Ignacio Goyret Lucent Technologies One Ascend Plaza 1701 Harbor Bay Parkway Alameda, CA 94502 Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Zorn, et al. Informational [Page 19] RFC 2868 RADIUS Tunnel Authentication Attributes June 200011. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.  Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Zorn, et al. Informational [Page 20]


Subpart 9.1—Responsible Prospective Contractors
9.104-3 Application of standards.
9.104-4 Subcontractor responsibility.
9.104-5 Representation and certifications regarding responsibility matters.
9.104-6 Federal Awardee Performance and Integrity Information System.
9.104-7 Solicitation provisions and contract clauses.
9.105-1 Obtaining information.
9.105-2 Determinations and documentation.
9.105-3 Disclosure of preaward information.
9.106-1 Conditions for preaward surveys.
9.106-2 Requests for preaward surveys.
9.106-3 Interagency preaward surveys.
9.107 Surveys of nonprofit agencies participating in the AbilityOne Program.
9.108 Prohibition on contracting with inverted domestic corporations.
9.108-3 Representation by the offeror.
9.108-5 Solicitation provision and contract clause.
Subpart 9.2—Qualifications Requirements
9.203 QPL’s, QML’s, and QBL’s.
9.204 Responsibilities for establishment of a qualification requirement.
9.205 Opportunity for qualification before award.
9.206 Acquisitions subject to qualification requirements.
9.207 Changes in status regarding qualification requirements.
Subpart 9.3—First Article Testing and Approval
9.306 Solicitation requirements.
9.307 Government administration procedures.
9.308-1 Testing performed by the contractor.
9.308-2 Testing performed by the Government.
Subpart 9.4—Debarment, Suspension, and Ineligibility
9.404 System for Award Management Exclusions.
9.405-1 Continuation of current contracts.
9.405-2 Restrictions on subcontracting.
9.407-2 Causes for suspension.
Subpart 9.5—Organizational and Consultant Conflicts of Interest
9.504 Contracting officer responsibilities.
9.505-1 Providing systems engineering and technical direction.
9.505-2 Preparing specifications or work statements.
9.505-3 Providing evaluation services.
9.505-4 Obtaining access to proprietary information.
9.507 Solicitation provisions and contract clause.
9.507-1 Solicitation provisions.
Subpart 9.6—Contractor Team Arrangements
Subpart 9.7—Defense Production Pools and Research and Development Pools
9.703 Contracting with individual pool members.


DataSourceDirective
is a standalone directive that includes most common logic when working with
the data sources.
Since it's a standalone directive, users don't need to manually apply it to a desired component. This can be
done with hostDirectives
object of the @Component
or
@Directive
decorator.
It handles opening and closing the data stream with the help of the class that implements
DataSourceParser
interface.
This class can be provided via FD_DATA_SOURCE_TRANSFORMER
Injection Token.
Additionally, it will emit events when the data inside data provider has been changed, or the data source object has been changed completely.


--- prev_page: '/examples/examples_empirical_distributions.html' next_page: '/examples/examples_variability_of_the_sample_mean.html' --- {% raw %}
# HIDDEN
# Clear previously defined variables
%reset -f
# HIDDEN
from datascience import *
import matplotlib
matplotlib.use('Agg', warn=False)
%matplotlib inline
import matplotlib.pyplot as plt
plt.style.use('fivethirtyeight')
import numpy as np
from ipywidgets import interact, interactive, fixed, interact_manual
import ipywidgets as widgets
import nbinteract as nbi
The law of averages also holds when the random sample is drawn from individuals in a large population.
As an example, we will study a population of flight delay times. The table united
contains data for United Airlines domestic flights departing from San Francisco in the summer of 2015. The data are made publicly available by the Bureau of Transportation Statistics in the United States Department of Transportation.
There are 13,825 rows, each corresponding to a flight. The columns are the date of the flight, the flight number, the destination airport code, and the departure delay time in minutes. Some delay times are negative; those flights left early.
united = Table.read_table('http://inferentialthinking.com/notebooks/united_summer2015.csv')
united
One flight departed 16 minutes early, and one was 580 minutes late. The other delay times were almost all between -10 minutes and 200 minutes, as the histogram below shows.
united.column('Delay').min()
united.column('Delay').max()
delay_opts = {
'xlabel': 'Delay (minute)',
'ylabel': 'Percent per minute',
'xlim': (-20, 600),
'ylim': (0, 0.045),
'bins': 62,
}
nbi.hist(united.column('Delay'), options=delay_opts)
For the purposes of this section, it is enough to zoom in on the bulk of the data and ignore the 0.8% of flights that had delays of more than 200 minutes. This restriction is just for visual convenience; the table still retains all the data.
united.where('Delay', are.above(200)).num_rows/united.num_rows
delay_opts = {
'xlabel': 'Delay (minute)',
'ylabel': 'Percent per minute',
'xlim': (-20, 200),
'ylim': (0, 0.045),
'bins': 22,
}
nbi.hist(united.column('Delay'), options=delay_opts)
The height of the [0, 10) bar is just under 3% per minute, which means that just under 30% of the flights had delays between 0 and 10 minutes. That is confirmed by counting rows:
united.where('Delay', are.between(0, 10)).num_rows/united.num_rows
Let us now think of the 13,825 flights as a population, and draw random samples from it with replacement. It is helpful to package our analysis code into a function. The function empirical_delays
takes the sample size as its argument and returns the array of sampled flight delays.
def empirical_hist_delay(sample_size):
return united.sample(sample_size).column('Delay')
As we saw with the dice, as the sample size increases, the empirical histogram of the sample more closely resembles the histogram of the population. Compare these histograms to the population histogram above.
nbi.hist(empirical_hist_delay,
options=delay_opts,
sample_size=widgets.ToggleButtons(options=[10, 100, 1000, 10000], description='Sample Size: '))
The most consistently visible discrepancies are among the values that are rare in the population. In our example, those values are in the the right hand tail of the distribution. But as the sample size increases, even those values begin to appear in the sample in roughly the correct proportions.
What we have observed in this section can be summarized as follows:
For a large random sample, the empirical histogram of the sample resembles the histogram of the population, with high probability.
This justifies the use of large random samples in statistical inference. The idea is that since a large random sample is likely to resemble the population from which it is drawn, quantities computed from the values in the sample are likely to be close to the corresponding quantities in the population.


China slams US over Hong Kong Bill
Beijing: China on Wednesday condemned the passing of the Hong Kong Human Rights and Democracy Act of 2019 in the US Senate. The US Senate passed the legislation on Tuesday despite strong opposition from the Chinese government, Xinhua reported. “The move grossly interfered in Hong Kong affairs and China’s internal affairs, seriously violated international laws and the basic norms governing international relations and blatantly bolstered the opposition and radical violent criminals in Hong Kong, which once again laid bare in front of the whole world the overbearing nature of some US politicians and their evil attempt to contain China’s development,” said Yang Guang, Spokesperson, Hong Kong and Macao Affairs Office of China’s State Council.
Yang said that the continuous violent activities in Hong Kong have seriously trampled the rule of law and social order, disturbed Hong Kong’s prosperity and stability, challenged the bottom line of the “one country, two systems” principle. He added that some of the violent behaviours were inhumane and appalling. “Facts have proved that the biggest risk facing Hong Kong now is rampant violence, not the so-called issue of democracy and human rights,” Yang said, adding that the behaviours of some US politicians have completely confused right and wrong and confounded black and white, and are double standards with total disregard to principles. (IANS)
Also Read: China sails 1st indigenous aircraft carrier through Taiwan Strait
Also Watch: Govt all set to push for the contentious Citizenship Bill in the winter session of Parliament


CONTENT 1
CONTENT 2
CONTENT 3
Variable to control the panel:
0
Collapsed height:
Don't change, it is calculated onLoad
based on size in design .
First section
Second section
Last section
Content switcher
Axure Kit
Carbon
Updates
Common widgets
Style effects
Variables
Selection group
Repeater
Dynamic panel
Introduction
Axure elements
Utilities
UI shell
Tooltip
Toggle
Tile
Text input
Tag
Tabs
Structured list
Slider
Select
Search
Radio button
Progress indicator
Pagination
Overflow menu
Number input
Notification
Modal
Loading
List
Link
Inline loading
Form
File upoader
Dropdown
Date picker
Data table
Content switcher
Code snippet
Checkbox
Button
Breadcrumb
Accordion
Components
Typography
Spacing
Icons
Color
Design elements
Library index
Getting started
Components
Privacy
Have questions? Open an issue on GitHub.
Last updated 29 January 2020
Copyright © 2020 IBM
Terms of Use
Contribute
IBM.com
Content switcher
Library section:
Interactions:
Form
Dynamic panel
Style effects
Selection group
Content is switched (dynamic panel).
–
Background is resized, below widgets are pushed/pulled when widget size is changing due to different content height in sections.
–
Implemented features
Content can be edited on states of the "pnl content" dynamic panel.
Content (panel state) is switched with the Selected event of a button shape.
A "background" element is included with the widget, this is the target of the resize actions. If you need a different background, don't replace it, just change styles of the included element.
To change number of sections, duplicate/remove middle section button (
) and panel states.
Edit other button:
–
[...]
/
buttons (G)
/
btn section 1
[...]
/
buttons (G)
/
btn section {n} (G)
/
btn shape
Edit first button:
–
[...]
/
pnl content
/
state:section {n}
Edit content:
–
Buttons are in a selection group, only one should be selected by default.
Usage
btn section 2 (G)


{% extends 'base.html'%} {% block content%}
Welcome to CodeWars API.
A site where you can have access to codewars challenges and share your solutions comments and likes on posted solutions


git diff [--options] [--] [
This form is to view the changes you made relative to the index (staging area for the next commit). In other words, the differences are what you could tell Git to further add to the index but you still haven’t. You can stage these changes by using git-add(1).
git diff [--options] --cached [
This form is to view the changes you staged for the next commit relative to the named


|
AAX SDK
2.3.1
Avid Audio Extensions Development Kit
|
#include <AAX_IDma.h>
Cross-platform interface for access to the host's direct memory access (DMA) facilities.
This interface is provided via a DMA port in the plug-in's algorithm context.
Public Types | |
| enum | EState { eState_Error = -1, eState_Init = 0, eState_Running = 1, eState_Complete = 2, eState_Pending = 3 } |
| enum | EMode { eMode_Error = -1, eMode_Burst = 6, eMode_Gather = 10, eMode_Scatter = 11 } |
| DMA mode IDs. More... | |
Public Member Functions | |
| virtual | ~AAX_IDma () |
Basic DMA operation | |
| virtual AAX_Result AAX_DMA_API | PostRequest ()=0 |
| Posts the transfer request to the DMA server. More... | |
| virtual int32_t AAX_DMA_API | IsTransferComplete ()=0 |
| Query whether a transfer has completed. More... | |
| virtual AAX_Result AAX_DMA_API | SetDmaState (EState iState)=0 |
| Sets the DMA State. More... | |
| virtual EState AAX_DMA_API | GetDmaState () const =0 |
| Inquire to find the state of the DMA instance. More... | |
| virtual EMode AAX_DMA_API | GetDmaMode () const =0 |
| Inquire to find the mode of the DMA instance. More... | |
Methods for Burst operation | |
Use these methods in conjunction with AAX_IDma::eMode_Burst | |
| virtual AAX_Result AAX_DMA_API | SetSrc (int8_t *iSrc)=0 |
| Sets the address of the source buffer. More... | |
| virtual int8_t *AAX_DMA_API | GetSrc ()=0 |
| Gets the address of the source buffer. More... | |
| virtual AAX_Result AAX_DMA_API | SetDst (int8_t *iDst)=0 |
| Sets the address of the destination buffer. More... | |
| virtual int8_t *AAX_DMA_API | GetDst ()=0 |
| Gets the address of the destination buffer. More... | |
| virtual AAX_Result AAX_DMA_API | SetBurstLength (int32_t iBurstLengthBytes)=0 |
| Sets the length of each burst. More... | |
| virtual int32_t AAX_DMA_API | GetBurstLength ()=0 |
| Gets the length of each burst. More... | |
| virtual AAX_Result AAX_DMA_API | SetNumBursts (int32_t iNumBursts)=0 |
| Sets the number of bursts to perform before giving up priority to other DMA transfers. More... | |
| virtual int32_t AAX_DMA_API | GetNumBursts ()=0 |
| Gets the number of bursts to perform before giving up priority to other DMA transfers. More... | |
| virtual AAX_Result AAX_DMA_API | SetTransferSize (int32_t iTransferSizeBytes)=0 |
| Sets the size of the whole transfer. More... | |
| virtual int32_t AAX_DMA_API | GetTransferSize ()=0 |
| Gets the size of the whole transfer, in Bytes. More... | |
Methods for Scatter and Gather operation | |
Use these methods in conjunction with AAX_IDma::eMode_Scatter and AAX_IDma::eMode_Gather | |
| virtual AAX_Result AAX_DMA_API | SetFifoBuffer (int8_t *iFifoBase)=0 |
| Sets the address of the FIFO buffer for the DMA transfer (usually the external memory block) More... | |
| virtual int8_t *AAX_DMA_API | GetFifoBuffer ()=0 |
| Gets the address of the FIFO buffer for the DMA transfer. More... | |
| virtual AAX_Result AAX_DMA_API | SetLinearBuffer (int8_t *iLinearBase)=0 |
| Sets the address of the linear buffer for the DMA transfer (usually the internal memory block) More... | |
| virtual int8_t *AAX_DMA_API | GetLinearBuffer ()=0 |
| Gets the address of the linear buffer for the DMA transfer. More... | |
| virtual AAX_Result AAX_DMA_API | SetOffsetTable (const int32_t *iOffsetTable)=0 |
| Sets the offset table for the DMA transfer. More... | |
| virtual const int32_t *AAX_DMA_API | GetOffsetTable ()=0 |
| Gets the offset table for the DMA transfer. More... | |
| virtual AAX_Result AAX_DMA_API | SetNumOffsets (int32_t iNumOffsets)=0 |
| Sets the number of offets in the offset table. More... | |
| virtual int32_t AAX_DMA_API | GetNumOffsets ()=0 |
| Gets the number of offets in the offset table. More... | |
| virtual AAX_Result AAX_DMA_API | SetBaseOffset (int32_t iBaseOffsetBytes)=0 |
| Sets the relative base offset into the FIFO where transfers will begin. More... | |
| virtual int32_t AAX_DMA_API | GetBaseOffset ()=0 |
| Gets the relative base offset into the FIFO where transfers will begin. More... | |
| virtual AAX_Result AAX_DMA_API | SetFifoSize (int32_t iSizeBytes)=0 |
| Sets the size of the FIFO buffer, in bytes. More... | |
| virtual int32_t AAX_DMA_API | GetFifoSize ()=0 |
| Gets the size of the FIFO buffer, in bytes. More... | |
| enum AAX_IDma::EState |
| enum AAX_IDma::EMode |
DMA mode IDs.
These IDs are used to bind DMA context fields to a particular DMA mode when describing the fields with AAX_IComponentDescriptor::AddDmaInstance()
| Enumerator | |
|---|---|
| eMode_Error | |
| eMode_Burst |
Burst mode (uncommon) |
| eMode_Gather |
Gather mode. |
| eMode_Scatter |
Scatter mode. |
|
inlinevirtual |
|
pure virtual |
Posts the transfer request to the DMA server.
AAX_SUCCESS
on success
|
pure virtual |
Query whether a transfer has completed.
A return value of false indicates an error, and that the DMA missed its cycle count deadline
|
pure virtual |
Sets the DMA State.
AAX_SUCCESS
on success
|
pure virtual |
Inquire to find the state of the DMA instance.
|
pure virtual |
Inquire to find the mode of the DMA instance.
This value does not change, so there is no setter.
|
pure virtual |
Sets the address of the source buffer.
| [in] | iSrc | Address of the location in the source buffer where the read transfer should begin |
AAX_SUCCESS
on success
|
pure virtual |
Gets the address of the source buffer.
|
pure virtual |
Sets the address of the destination buffer.
| [in] | iDst | Address of the location in the destination buffer where the write transfer should begin |
AAX_SUCCESS
on success
|
pure virtual |
Gets the address of the destination buffer.
|
pure virtual |
Sets the length of each burst.
AAX_SUCCESS
on success
|
pure virtual |
Gets the length of each burst.
|
pure virtual |
Sets the number of bursts to perform before giving up priority to other DMA transfers.
Valid values are 1, 2, 4, or 16.
The full transmission may be broken up into several series of bursts, and thus the total size of the data being transferred is not bounded by the number of bursts times the burst length.
| [in] | iNumBursts | The number of bursts |
AAX_SUCCESS
on success
|
pure virtual |
Gets the number of bursts to perform before giving up priority to other DMA transfers.
|
pure virtual |
Sets the size of the whole transfer.
| [in] | iTransferSizeBytes | The transfer size, in Bytes |
AAX_SUCCESS
on success
|
pure virtual |
Gets the size of the whole transfer, in Bytes.
|
pure virtual |
Sets the address of the FIFO buffer for the DMA transfer (usually the external memory block)
AAX_SUCCESS
on success
|
pure virtual |
Gets the address of the FIFO buffer for the DMA transfer.
|
pure virtual |
Sets the address of the linear buffer for the DMA transfer (usually the internal memory block)
AAX_SUCCESS
on success
|
pure virtual |
Gets the address of the linear buffer for the DMA transfer.
|
pure virtual |
Sets the offset table for the DMA transfer.
The offset table provides a list of Byte-aligned memory offsets into the FIFO buffer. The transfer will be broken into a series of individual bursts, each beginning at the specified offset locations within the FIFO buffer. The size of each burst is set by SetBurstLength().
AAX_SUCCESS
on success
|
pure virtual |
Gets the offset table for the DMA transfer.
|
pure virtual |
Sets the number of offets in the offset table.
AAX_SUCCESS
on success
|
pure virtual |
Gets the number of offets in the offset table.
|
pure virtual |
Sets the relative base offset into the FIFO where transfers will begin.
The base offset will be added to each value in the offset table in order to determine the starting offset within the FIFO buffer for each burst.
AAX_SUCCESS
on success
|
pure virtual |
Gets the relative base offset into the FIFO where transfers will begin.
|
pure virtual |
Sets the size of the FIFO buffer, in bytes.
AAX_SUCCESS
on success
|
pure virtual |
Gets the size of the FIFO buffer, in bytes.


| DOSE: |
50 mg |
insufflated |
5-MeO-DMT |
(powder / crystals) |
I've always been a fan of acid and shrooms, so when I saw the video 'Flashback' it really got me wanting to try 5-MeO-DMT. None of my friends have ever tried it, so I found a website and ordered 100mgs using my mom's credit card. Less than a week later it came in the mail. I had enough for 10 10mg trips so i promised a few of my friends I'd let em try it out.
The day after it came me and my best friends Andrew and Mitch were getting stoned before going to mall as we do all the time. Only this time would be a little bit different on the count of I had the 5-MeO-DMT with me. Since Mitch was the one driving he didn't want to do any, so me and Andrew tried smoking it out of my chillium with not much success on the count of the big crystal we had in the bowl melted, needless to say however we did get a hit.
  The drip was horrible.
 I fealt good but that didn't last long. Soon my face started turning bright red then the fact that I bumped 50 mgs on top of taking a hit of that when all you're supposed to take is 10 so I became very paranoid I was going to die. Time slowed down times ten. I was sooo out of it that it took all the concentration I had to get my phone out of my pockit to hand it to Andrew.
Talking yet still making sence was also very hard too. I was terrified i was going to die, and since time seemed like it was slowing down I was sure that was it. I was going to overdose on 5-MeO-DMT in a Burger King. But after what seemed like 5 minutes (but in actuality was 40) I started to mellow out, thus when the actual tripping part kicked in. It fealt like my eye started to melt and drip down my face like tears and I could see the color of my eyes running down my face but nothing was there when I went to wipe it off which I found funny. And when I talked, I'd see the right part of my bottom lip stretch out really far in front of me.
Around the time the tripping started to kick in, I had fealt like I was at my peak of 10 e pills. (E is my FAVORITE drug by the way) It was amazing how I fealt, to this day I can't even describe it. Everything seemeed so perfect and my mind was overflowing with the most amazing sentences I thought could ever be spoken.  I didn't have any out of body expieriences or travel to a different world, but then again I was too concerned I was going to overdose, not to mention in a resteraunt full of ppl who were staring at me like I was on drugs.
 Also, I'll do it with ppl I trust and will calm me down if I start to panic, not people who will just make fun of me making things worse. And I won't go to a public place because I in no way can act at all sober on this drug. Since then I havn't used any, but I'm ordering 200 mgs soon and sticking with 25-30mg doses.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


CrawlMaze - Testbed for Web Crawlers - multi-step request with event attribute
multi-step GET method based on redefining the button's onclick function
When the button is clicked, an eventListener is added that sends a GET request via JavaScript fetch. This is a somewhat odd edge-case, since we define several events that occur at once when clicking the button.


Key: = Must support, = QICore-defined extension, = Is-Modifier
| Field | Card. | Type and Description |
|---|---|---|
| accident |
0..1
|
Accident
|
| billablePeriod |
0..1
|
interval<DateTime>
|
| coverage |
0..*
|
List<Coverage>
|
| created |
0..1
|
DateTime
|
| diagnosis |
0..*
|
List<Diagnosis>
|
| employmentImpacted |
0..1
|
interval<DateTime>
|
| enterer[x] |
0..1
|
Identifier | Practitioner
|
| facility[x] |
0..1
|
Identifier | Location
|
| fundsReserve |
0..1
|
Code
|
| hospitalization |
0..1
|
interval<DateTime>
|
| identifier |
0..*
|
List<Identifier>
|
| information |
0..*
|
List<Information>
|
| insurer[x] |
0..1
|
Identifier | Organization
|
| item |
0..*
|
List<Item>
|
| missingTeeth |
0..*
|
List<MissingTeeth>
|
| organization[x] |
0..1
|
Identifier | Organization
|
| originalPrescription[x] |
0..1
|
Identifier | MedicationOrder
|
| originalRuleset |
0..1
|
Code
|
| patient[x] |
1..1
|
Identifier | Patient
|
| payee |
0..1
|
Payee
|
| prescription[x] |
0..1
|
Identifier | MedicationOrder | VisionPrescription
|
| priority |
0..1
|
Code
|
| procedure |
0..*
|
List<Procedure>
|
| provider[x] |
0..1
|
Identifier | Practitioner
|
| referralReference |
0..1
|
ReferralRequest
|
| related |
0..*
|
List<Related>
|
| ruleset |
0..1
|
Code
|
| status |
1..1
|
code
|
| subType |
0..*
|
List<Code>
|
| total |
0..1
|
Money
|
| type |
1..1
|
Code
|
| use |
0..1
|
code
|
Key: = Must support, = QICore-defined extension, = Is-Modifier


What you enter here will be prepended to the launch command.
The actual command being issued will be the concatenation of Prefix Start Slave Command, the command to launch slave.jar and Suffix Start Slave Command, without any separators.


Issues in Tech
After much research, it seems that the tech industry is riddled with problems and not enough developers in the world to fix them all. This probably stems from the fact the the tech industry is constantly evolving. It is evolving at a much faster pace than any of us can keep up with. One issue however that caught my attention and I couldn't help but agree with is that, technology doesn't always work... As simple as it may seem, when you stop to consider it for a moment you realize all the implications this can have. Sure, we feel the daily fustrations of ineffective technology all the time. Our GPS on our phone never seems to work when we REALLY need it, our laptops crash and we lose months worth of personal data, etc... But what we fail to realize is that the fact that technology is advancing daily means we rely on it more and more for bigger and more important things.
Our lives have gotten to a point that we can control everything from the palm of our hands. But what happens when the technology on the other end stops working. Sure, your Bank App may be on the fritz and you are temporarily locked out of the system, but you'll be back on soon enough. All it takes is a quick phone call to your local bank on your lunch break. But what happens when the technology running the bank is on the fritz. Technology at that level has the potential to reveal sensitive customer data or even bring cities to a temporary halt. In the case of American Airlines, defective technology and system glitches caused them to ground all their planes. We are accepting these advances in technology with a blind eye and relying fully on them without taking any precautions and without realizing that the technology may not yet be capable to fully meet all our needs.
What can we do to aleviate the stress of ineffective technology? I for one tend to rely heavily on it. I trust in Google more than anything else. Which when you think about it, says a lot. Google like anything is a brand anf if you ask anyone, for the most part they will tell you that it is probably their preffered engine of choice. Why is that? Because Google strives to always be effective. They have the best people working on the best technology, all the time. They catch and glitches, and slip-ups before they can ever affect us. The idea is not to stop relying on technlogy or to set up a back-up plan against faulty technology, but rather for the tech companies to implement a higher standard. Of course, nobody is perfect and accidents do happen but if we could put our trust in ALL the technology we use on a daily basis the same way we put our trust in names like Google, the world could be a safer place... technically.


HTML 5: The backbone of web development. Focusing on ensuring semantic tag usage.
CSS: Learning new things with CSS daily. Familiar with Flexbox.
Bootstrap: Utilizes CSS and Javascript to create mobile-friendly and responsive web sites.
Git: Version control software for tracking changes you make to projects.
Github: Web-based git hosting service. Very useful for programmers to collaborate on code.


--- title: "Reschedule a citizenship appointment: Empowering applicants and frontline staff" description: "The goal of our partnership with Immigration, Refugees and Citizenship Canada (IRCC) is to make the process of rescheduling a citizenship appointment as convenient and stress-free as possible for applicants, whilst empowering frontline staff. " author: Hillary Lorimer and Mithula Naik date: 2018-04-13 09:00:00 -0400 image: blog-ircc-april.jpg image-alt: The waiting area at an IRCC client support centre with nine stations at the service counter. lang: en layout: cds/post trans_url: "/2018/04/13/reporter-un-rendez-vous-dexamen" ---
The goal of our partnership with Immigration, Refugees and Citizenship Canada (IRCC) is to make the process of rescheduling a citizenship appointment as convenient and stress-free as possible for applicants, whilst empowering frontline staff.
We started by doing research to understand the needs, hopes, and concerns of people applying for Canadian citizenship. Working closely with our operational delivery colleagues at IRCC, our aim is to identify opportunities to improve the service for both applicants and frontline staff.
In our previous blog post, we shared some of the field research methods used by the team. We’re now going to delve deeper into that research, and how we’re using what we learned to inform the next phase of our work.
Basing ourselves in the Vancouver citizenship office, we carried out short intercept interviews with applicants. Some had been successful rescheduling their appointment. Others had been too nervous to try, for fear of negative consequences. Frontline office and call center staff reported a high volume of enquiries from applicants waiting to be rescheduled, who were worried about the status of their citizenship application. It was clear that anxiety and uncertainty were having a negative impact on the client experience and placing an unnecessary burden on IRCC staff.
Currently, applicants need to write a letter or send an email asking to reschedule their appointment. Our colleagues at IRCC gave us access over fifty of these letters and emails, which helped us understand what applicants were thinking and feeling.
When an applicant is notified of their test or ceremony appointment, they’re worried about having to rearrange other commitments so they can attend.
Having to rearrange personal and professional commitments can be tricky. In some cases, this can come with serious financial and personal costs. Helping applicants plan appointments around their existing schedule gives them a greater sense of control.
People fear that interrupting a government process could put their entire citizenship application at risk. In particular, the potential impact of not attending can cause high anxiety:
As a result, many applicants completely avoid rescheduling, even if it means missing important life events such as weddings or graduation ceremonies. For those who do decide to reschedule, they enter the process already anxious about the outcome of their decision.
Once applicants send their request to reschedule, it’s not clear to them what happens next. There may be no indication that their request was received, and they can start to worry about still having to attend the original appointment.
As applicants grow more concerned about the status of their request, we see a spike in inquiries to the IRCC call centre and local offices. By providing applicants with clearer advice on what to expect, and keeping them updated on progress, we can reduce anxiety and minimize the need to contact IRCC.
The appointment notification states that applicants should have a valid reason to reschedule. However, it’s not clear what this means. We read many long letters and emails from applicants, which surfaced three common themes:
Together with our colleagues at IRCC we’re looking at ways to reduce ambiguity for applicants and make the conditions for rescheduling clearer.
The Citizenship product team are working closely with our colleagues at IRCC to incorporate these insights into the design of the service. During this Alpha phase, we will be:
By continuing to conduct on-site research and usability testing, we can support the broader drive towards more user-centric service delivery at IRCC. Together we share their vision for a clear and simple service that allows future citizens to reschedule their interview for a time that meets their needs, with minimal intervention by staff.
Follow our Twitter accounts and keep an eye on our blog for updates as we progress.


After running very good and stable since March, my system suddenly developed an issue on December 27, 13.50 hours GMT+1
At that time, Emoncms report the time to be off by -1305995336 seconds (41 years), and the feeds seem no longer to update. I corrected the time zone in the Pi and Emoncms.org to GMT+1 and rebooted the Raspberry Pi, but unfortunately no joy.
Anyone have an idea where I should start to look? thanks!
Re: Clock off by -1305995336 sec :-/
Have you tried to log in to your Raspberry Pi and try the
command at the bash shell? If that's wrong, then it's probably not an emon/oem problem and you should be able to Google for a solution that applies to Raspberry Pi's in general.
Re: Clock off by -1305995336 sec :-/
Thanks for the reply :-)
Date and clock is OK on the Raspberry Pi, so that's probably not the problem. When I check, not all services are running.
Just realized that the SD card seems to be fried; only 0.1 Gb out of the original 4 Gb is now available.
I have therefore decided to do an update of the SW on a fresh SD card; needed to do that at some point anyway. Hope that solves the problem without scrambling all my old data :-)
Re: Clock off by -1305995336 sec :-/
I now have the new Raspberry Pi firmware up running. The data is logging nicely on the RP, but I fail to get the data transferred to Emoncms.org. Any suggestions?
Re: Clock off by -1305995336 sec :-/
I created at new user on Emoncms.org. Everything seems to work fine using the new account, i.e. data is uploaded w/o any issues..
Please advise, I would really like to keep my old data :-/
Re: Clock off by -1305995336 sec :-/
This may be aa issue with your emoncms.org account.
Not only have you now successfully posted to a new account, but the log above clearly shows it got an "ok" response from emoncms.org when you say it wasn't updating, either it's posting to wrong account or there is an internal error on that account at the server. Are you 100% sure the apikey is correct?
This may need looking into at the server end. I seem to have a vague recollection of this happening before but I cannot find anything via a search.
Paul
Re: Clock off by -1305995336 sec :-/
Hi Paul,
I tried once again to copy/paste the api key from my old account into the Emonhub configuration file. Unfortunately it still dosn't work. I reverted the input back to the new account and started logging a few inputs.
Is there anything else I can do? If needed, I can PM you my account/PW details for emoncms.org.
Thanks in advance, sorry to cause any trouble!
Re: Clock off by -1305995336 sec :-/
As a temporary measure you could duplicate the emoncms.org instance settings (in emonhub.conf) with a different name eg emoncmsorg2 (and api keys) for the "new" account so that you are posting to both accounts, at the moment you do not know the old account isn't logging, just that you cannot see it logging, the "ok" may suggest otherwise.
I say this as you may not be able to transfer any newly collected data to your old account from your new account so if there is any chance it's still working that would be better, but the new account does mean you have the data either way, it's just damage limitation to minimize any data loss.
I do not have server access so cannot help you there, that would need to be Trystan or Glyn. I have seen Glyn on the forum in the last couple of days but not Trystan, hopefully one of them will see this or perhaps one of the mods could PM/email them on your behalf?
Paul
Re: Clock off by -1305995336 sec :-/
Good call Paul, thanks. I have now added both api keys to the config file, maybe some data will be rescued.
Hope Glyn or Trystan will be able to resolve the issue.
Re: Clock off by -1305995336 sec :-/
Hello Lykke, very sorry for this, can you check your account now it should be fixed.
Trystan
Re: Clock off by -1305995336 sec :-/
Hi Trystan,
Thanks a lot :-) Now it all works again!
No real damage done; lost a few days of data but forced me to the update the firmware and recover the OEM files from my old crashed laptop. Nice little Christmas soduko ;-)
Happy New Year
Lykke
Re: Clock off by -1305995336 sec :-/
I've added an automated check for this issue which is caused by the input limiters which limit posting on emonms.org to 1 post every 5 seconds. I need to do a bit more work to fully sort and test this issue but at least in the mean time there is now a cron job that clears the limiters for any accounts that have this issue once an hour.
Re: Clock off by -1305995336 sec :-/
Ah, didn't realize there was a posting limit.
I'm feeding 10 inputs; 3 phases + 2 PV arrays + 1 EV charger + 2 Voltages + 2 Inactive inputs (future use). Would it improve the situation if I were to erase the two inactive inputs?
Re: Clock off by -1305995336 sec :-/
The rough data point from the period where I could not upload any data is messing up the accumulated values, e.g kWh used.
I can not figure out if theres a way to edit the data and delete the meaningless ones... Maybe it's better to "cheat" and correct the sums in the feed process list and zero everything for New Year?


Style Guide
Style Guide Metadata
Version 1.1.2
1. Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, ”MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
2. Puppet Version
This style guide is largely specific to Puppet versions 2.6.x; some of its recommendations are based on some language features that became available in version 2.6.0 and later.
3. Why a Style Guide?
Puppet Labs develops modules for customers and the community, and these modules should represent the best known practice for module design and style. Since these modules are developed by many people across the organisation, a central reference was needed to ensure a consistent pattern, design, and style.
4. General Philosophies
No style manual can cover every possible circumstance. When a judgement call becomes necessary, keep in mind the following general ideas:
- Readability matters. If you have to choose between two equally effective alternatives, pick the more readable one. This is, of course, subjective, but if you can read your own code three months from now, that’s a great start.
- Inheritance should be avoided. In general, inheritance leads to code that is harder to read. Most use cases for inheritance can be replaced by exposing class parameters that can be used to configure resource attributes. See the Class Inheritance section for more details.
- Modules must work with an ENC without requiring one. An internal survey yielded near consensus that an ENC should not be required. At the same time, every module we write should work well with an ENC.
- Classes should generally not declare other classes. Declare classes as close to node scope as possible. Classes which require other classes should not directly declare them and should instead allow the system to fail if they are not declared by some other means. (Although the include function allows multiple declarations of classes, it can result in non-deterministic scoping issues due to the way parent scopes are assigned. We might revisit this philosophy in the future if class multi-declarations can be made deterministic, but for now, be conservative with declarations.)
5. Module Metadata
Every module must have Metadata defined in the Modulefile data file and outputted as the metadata.json file. The following Metadata should be provided for all modules:
name 'myuser-mymodule'
version '0.0.1'
author 'Author of the module - for shared modules this is Puppet Labs'
summary 'One line description of the module'
description 'Longer description of the module including an example'
license 'The license the module is release under - generally GPLv2 or Apache'
project_page 'The URL where the module source is located'
dependency 'otheruser/othermodule', '>= 1.2.3'
A more complete guide to the Modulefile format can be found in the puppet-module-tool README.
5.1. Style Versioning
This style guide will be versioned, which will allow modules to comply with a specific version of the style guide.
A future version of the puppet-module tool may permit the relevant style guide version to be embedded as metadata in the Modulefile, and the metadata in turn may be used for automated linting.
6. Spacing, Indentation, & Whitespace
Module manifests complying with this style guide:
- Must use two-space soft tabs
- Must not use literal tab characters
- Must not contain trailing white space
- Should not exceed an 80 character line width
- Should align fat comma arrows (
=>
) within blocks of attributes
7. Comments
Although the Puppet language allows multiple comment types, we prefer
hash/octothorpe comments (# This is a comment
) because they’re generally the
most visible to text editors and other code lexers.
- Should use
# ...
for comments - Should not use
// ...
or/* ... */
for comments
8. Quoting
All strings that do not contain variables should be enclosed in single quotes. Double quotes should be used when variable interpolation is required. Double quotes may also be used to make a string more readable when it contains single quotes. Quoting is optional when the string is an alphanumeric bare word and is not a resource title.
All variables should be enclosed in braces when interpolated in a string. For example:
Good:
"/etc/${file}.conf"
"${::operatingsystem} is not supported by ${module_name}"
Bad:
"/etc/$file.conf"
"$::operatingsystem is not supported by $module_name"
Variables standing by themselves should not be quoted. For example:
Good:
mode => $my_mode
Bad:
mode => "$my_mode"
mode => "${my_mode}"
9. Resources
9.1. Resource Names
All resource titles should be quoted. (Puppet supports unquoted resource titles if they do not contain spaces or hyphens, but you should avoid them in the interest of consistent look-and-feel.)
Good:
package { 'openssh': ensure => present }
Bad:
package { openssh: ensure => present }
9.2. Arrow Alignment
All of the fat comma arrows (=>
) in a resource’s attribute/value list should
be aligned. The arrows should be placed one space ahead of the longest
attribute name.
Good:
exec { 'blah':
path => '/usr/bin',
cwd => '/tmp',
}
exec { 'test':
subscribe => File['/etc/test'],
refreshonly => true,
}
Bad:
exec { 'blah':
path => '/usr/bin',
cwd => '/tmp',
}
exec { 'test':
subscribe => File['/etc/test'],
refreshonly => true,
}
9.3. Attribute Ordering
If a resource declaration includes an ensure
attribute, it should be the
first attribute specified.
Good:
file { '/tmp/readme.txt':
ensure => file,
owner => '0',
group => '0',
mode => '0644',
}
(This recommendation is solely in the interest of readability, as Puppet ignores attribute order when syncing resources.)
9.4. Compression
Within a given manifest, resources should be grouped by logical relationship to each other, rather than by resource type. Use of the semicolon syntax to declare multiple resources within a set of curly braces is not recommended, except in the rare cases where it would improve readability.
Good:
file { '/tmp/a':
content => 'a',
}
exec { 'change contents of a':
command => 'sed -i.bak s/a/A/g /tmp/a',
}
file { '/tmp/b':
content => 'b',
}
exec { 'change contents of b':
command => 'sed -i.bak s/b/B/g /tmp/b',
}
Bad:
file {
"/tmp/a":
content => "a";
"/tmp/b":
content => "b";
}
exec {
"change contents of a":
command => "sed -i.bak s/b/B/g /tmp/a";
"change contents of b":
command => "sed -i.bak s/b/B/g /tmp/b";
}
9.5. Symbolic Links
In the interest of clarity, symbolic links should be declared by using an
ensure value of ensure => link
and explicitly specifying a value for the
target
attribute. Using a path to the target as the ensure value is not
recommended.
Good:
file { '/var/log/syslog':
ensure => link,
target => '/var/log/messages',
}
Bad:
file { '/var/log/syslog':
ensure => '/var/log/messages',
}
9.6. File Modes
File modes should be represented as 4 digits rather than 3.
In addition, file modes should be specified as single-quoted strings instead of bare word numbers.
Good:
file { '/var/log/syslog':
ensure => present,
mode => '0644',
}
Bad:
file { '/var/log/syslog':
ensure => present,
mode => 644,
}
9.7. Resource Defaults
Resource defaults should be used in a very controlled manner, and should only be declared at the edges of your manifest ecosystem. Specifically, they may be declared:
- At top scope in site.pp
- In a class which is guaranteed to never declare another class and never be inherited by another class.
This is due to the way resource defaults propagate through dynamic scope, which can have unpredictable effects far away from where the default was declared.
Good:
# /etc/puppetlabs/puppet/manifests/site.pp:
File {
mode => '0644',
owner => 'root',
group => 'root',
}
Bad:
# /etc/puppetlabs/puppet/modules/ssh/manifests/init.pp
File {
mode => '0600',
owner => 'nobody',
group => 'nogroup',
}
class {'ssh::client':
ensure => present,
}
10. Conditionals
10.1. Keep Resource Declarations Simple
You should not intermingle conditionals with resource declarations. When using conditionals for data assignment, you should separate conditional code from the resource declarations.
Good:
$file_mode = $::operatingsystem ? {
debian => '0007',
redhat => '0776',
fedora => '0007',
}
file { '/tmp/readme.txt':
content => "Hello World\n",
mode => $file_mode,
}
Bad:
file { '/tmp/readme.txt':
mode => $::operatingsystem ? {
debian => '0777',
redhat => '0776',
fedora => '0007',
}
}
10.2. Defaults for Case Statements and Selectors
Case statements should have default cases. Additionally, the default case should fail the
catalog compilation when the resulting behavior cannot be predicted on the
majority of platforms the module will be used on. If you want the default case to be “do nothing,” include it as an explicit default: {}
for clarity’s sake.
For selectors, default selections should only be omitted if you explicitly want catalog compilation to fail when no value matches.
The following example follows the recommended style:
case $::operatingsystem {
centos: {
$version = '1.2.3'
}
solaris: {
$version = '3.2.1'
}
default: {
fail("Module ${module_name} is not supported on ${::operatingsystem}")
}
}
11. Classes
11.1. Separate Files
All classes and resource type definitions must be in separate files in the
manifests
directory of their module. For example:
# /etc/puppetlabs/puppet/modules/apache/manifests
# init.pp
class apache { }
# ssl.pp
class apache::ssl { }
# virtual_host.pp
define apache::virtual_host () { }
This is functionally identical to declaring all classes and defines in init.pp, but highlights the structure of the module and makes everything more legible.
11.2. Internal Organization of a Class
Classes should be organised with a consistent structure and style. In the below list there is an implicit statement of “should be at this relative location” for each of these items. The word “may” should be interpreted as “If there are any X’s they should be here”.
- Should define the class and parameters
- Should validate any class parameters and fail catalog compilation if any parameters are invalid
- Should default any validated parameters to the most general case
- May declare local variables
- May declare relationships to other classes
Class['apache'] -> Class['local_yum']
- May override resources
- May declare resource defaults
- May declare resources; resources of defined and custom types should go before those of core types
- May declare resource relationships inside of conditionals
The following example follows the recommended style:
class myservice($ensure='running') {
if $ensure in [ running, stopped ] {
$ensure_real = $ensure
} else {
fail('ensure parameter must be running or stopped')
}
case $::operatingsystem {
centos: {
$package_list = 'openssh-server'
}
solaris: {
$package_list = [ SUNWsshr, SUNWsshu ]
}
default: {
fail("Module ${module_name} does not support ${::operatingsystem}")
}
}
$variable = 'something'
Package { ensure => present, }
File { owner => '0', group => '0', mode => '0644' }
package { $package_list: }
file { "/tmp/${variable}":
ensure => present,
}
service { 'myservice':
ensure => $ensure_real,
hasstatus => true,
}
}
11.3. Relationship Declarations
Relationship declarations with the chaining syntax should only be used in the “left to right” direction.
Good:
Package['httpd'] -> Service['httpd']
Bad:
Service['httpd'] <- Package['httpd']
When possible, you should prefer metaparameters to relationship declarations. One example where metaparameters aren’t desirable is when subclassing would be necessary to override behavior; in this situation, relationship declarations inside of conditionals should be used.
11.4. Classes and Defined Resource Types Within Classes
Classes and defined resource types must not be defined within other classes.
Bad:
class apache {
class ssl { ... }
}
Also bad:
class apache {
define config() { ... }
}
11.5. Class Inheritance
Inheritance may be used within a module, but must not be used across module namespaces. Cross-module dependencies should be satisfied in a more portable way that doesn’t violate the concept of modularity, such as with include statements or relationship declarations.
Good:
class ssh { ... }
class ssh::client inherits ssh { ... }
class ssh::server inherits ssh { ... }
class ssh::server::solaris inherits ssh::server { ... }
Bad:
class ssh inherits server { ... }
class ssh::client inherits workstation { ... }
class wordpress inherits apache { ... }
Inheritance in general should be avoided when alternatives are viable. For example, instead of using inheritance to override relationships in an existing class when stopping a service, consider using a single class with an ensure parameter and conditional relationship declarations:
class bluetooth($ensure=present, $autoupgrade=false) {
# Validate class parameter inputs. (Fail early and fail hard)
if ! ($ensure in [ "present", "absent" ]) {
fail("bluetooth ensure parameter must be absent or present")
}
if ! ($autoupgrade in [ true, false ]) {
fail("bluetooth autoupgrade parameter must be true or false")
}
# Set local variables based on the desired state
if $ensure == "present" {
$service_enable = true
$service_ensure = running
if $autoupgrade == true {
$package_ensure = latest
} else {
$package_ensure = present
}
} else {
$service_enable = false
$service_ensure = stopped
$package_ensure = absent
}
# Declare resources without any relationships in this section
package { [ "bluez-libs", "bluez-utils"]:
ensure => $package_ensure,
}
service { hidd:
enable => $service_enable,
ensure => $service_ensure,
status => "source /etc/init.d/functions; status hidd",
hasstatus => true,
hasrestart => true,
}
# Finally, declare relations based on desired behavior
if $ensure == "present" {
Package["bluez-libs"] -> Package["bluez-utils"]
Package["bluez-libs"] ~> Service[hidd]
Package["bluez-utils"] ~> Service[hidd]
} else {
Service["hidd"] -> Package["bluez-utils"]
Package["bluez-utils"] -> Package["bluez-libs"]
}
}
(This example makes several assumptions and is based on an example provided in the Puppet Master training for managing bluetooth.)
In summary:
- Class inheritance is only useful for overriding resource attributes; any other use case is better accomplished with other methods.
- If you just need to override relationship metaparameters, you should use a single class with conditional relationship declarations instead of inheritance.
- In many cases, even other attributes (e.g. ensure and enable) may have their behavior changed with variables and conditional logic instead of inheritance.
11.6. Namespacing Variables
When using top-scope variables, including facts, Puppet modules should explicitly specify the empty namespace to prevent accidental scoping issues.
Good:
$::operatingsystem
Bad:
$operatingsystem
11.7. Variable format
When defining variables you should only use letters, numbers and underscores. You should specifically not make use of dashes.
Good:
$foo_bar123
Bad:
$foo-bar123
11.8. Display Order of Class Parameters
In parameterized class and defined resource type declarations, parameters that are required should be listed before optional parameters (i.e. parameters with defaults).
Good:
class ntp (
$servers,
$options = "iburst",
$multicast = false
) {}
Bad:
class ntp (
$options = "iburst",
$servers,
$multicast = false
) {}
11.9 Class parameter defaults
When writing a module that accepts class parameters sane defaults SHOULD be provided for optional parameters to allow the end user the option of not explicitly specifying the parameter when declaring the class.
For example:
class ntp(
$server = 'UNSET'
) {
include ntp::params
$server_real = $server ? {
'UNSET' => $::ntp::params::server,
default => $server,
}
notify { 'ntp':
message => "server=[$server_real]",
}
}
The reason this class is declared in this manner is to be fully compatible with all Puppet 2.6.x versions. The following alternative method SHOULD NOT be used because it is not compatible with Puppet 2.6.2 and earlier.
class ntp(
$server = $ntp::params::server
) inherits ntp::params {
notify { 'ntp':
message => "server=[$server]",
}
}
Other SHOULD recommendations:
- SHOULD use the _real suffix to indicate a scope local variable for maintainability over time.
- SHOULD use fully qualified namespace variables when pulling the value from the module params class to avoid namespace collisions.
- SHOULD declare the params class so the end user does not have to for the module to function properly.
This recommended pattern may be relaxed when Puppet 2.7 is more widely adopted and module compatibility with as many versions of 2.6.x is no longer a primary concern.
This diff illustrates the changes between these two commonly used patterns and how to switch from one to the other.
diff --git a/manifests/init.pp b/manifests/init.pp
index c16c3a0..7923ccb 100644
--- a/manifests/init.pp
+++ b/manifests/init.pp
@@ -12,9 +12,14 @@
#
class paramstest (
$mandatory,
- $param = $paramstest::params::param
-) inherits paramstest::params {
+ $param = 'UNSET'
+) {
+ include paramstest::params
+ $param\_real = $param ? {
+ 'UNSET' => $::paramstest::params::param,
+ default => $param,
+ }
notify { 'TEST':
- message => " param=[$param] mandatory=[$mandatory]",
+ message => " param=[$param\_real] mandatory=[$mandatory]",
}
}
12. Tests
All manifests should have a corresponding test manifest in the module’s tests
directory.
modulepath/apache/manifests/{init,ssl}.pp
modulepath/apache/tests/{init,ssl}.pp
The test manifest should provide a clear example of how to declare the class or
defined resource type. In addition, the test manifest should also declare any
classes required by the corresponding class to ensure puppet apply
works in a
limited, stand alone manner.
13. Puppet Doc
Classes and defined resource types should be documented inline using RDoc markup. These inline documentation comments are important because online documentation can then be easily generated using the puppet doc command.
For classes:
# == Class: example_class
#
# Full description of class example_class here.
#
# === Parameters
#
# Document parameters here.
#
# [*ntp_servers*]
# Explanation of what this parameter affects and what it defaults to.
# e.g. "Specify one or more upstream ntp servers as an array."
#
# === Variables
#
# Here you should define a list of variables that this module would require.
#
# [*enc_ntp_servers*]
# Explanation of how this variable affects the funtion of this class and if it
# has a default. e.g. "The parameter enc_ntp_servers must be set by the
# External Node Classifier as a comma separated list of hostnames." (Note,
# global variables should not be used in preference to class parameters as of
# Puppet 2.6.)
#
# === Examples
#
# class { 'example_class':
# ntp_servers => [ 'pool.ntp.org', 'ntp.local.company.com' ]
# }
#
# === Authors
#
# Author Name<EMAIL_ADDRESS>#
# === Copyright
#
# Copyright 2011 Your name here, unless otherwise noted.
#
class example_class {
}
For defined resources:
# == Define: example_resource
#
# Full description of defined resource type example_resource here.
#
# === Parameters
#
# Document parameters here
#
# [*namevar*]
# If there is a parameter that defaults to the value of the title string
# when not explicitly set, you must always say so. This parameter can be
# referred to as a "namevar," since it's functionally equivalent to the
# namevar of a core resource type.
#
# [*basedir*]
# Description of this variable. For example, "This parameter sets the
# base directory for this resource type. It should not contain a trailing
# slash."
#
# === Examples
#
# Provide some examples on how to use this type:
#
# example_class::example_resource { 'namevar':
# basedir => '/tmp/src',
# }
#
# === Authors
#
# Author Name<EMAIL_ADDRESS>#
# === Copyright
#
# Copyright 2011 Your name here, unless otherwise noted.
#
define example_class::example_resource($basedir) {
}
This will allow documentation to be automatically extracted with the puppet doc tool.


RT @mishkez: “Dad, how does Santa know if you’ve been bad or good, all the time?”
“Backdoored crypto protocols, son.”
9/9/2013, 11:50:13 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @mishkez: “Dad, how does Santa know if you’ve been bad or good, all the time?”
“Backdoored crypto protocols, son.”
9/9/2013, 11:50:13 AM
Favs: 0
Retweets: 0
link